Choose the Argon2 lane count for your CPU, and check the minimum memory and per-lane allocation it forces.
Argon2 divides its memory matrix into p lanes and each lane into four segments, letting p threads work a segment at a time. Lanes above the thread count you can actually schedule add synchronisation overhead without adding cost for the attacker. Setting p higher than the cores you own slows your own logins while leaving attacker cost unchanged, and choosing p without checking the 8 × p memory minimum produces a configuration the library will simply reject.
Argon2 Parallelism
p = available hardware threads, capped at 16; each lane gets m ÷ p KiB split into 4 segments, and m must be ≥ 8 × p.
p = available hardware threads, capped at 16; each lane gets m ÷ p KiB split into 4 segments, and m must be ≥ 8 × p. Argon2 divides its memory matrix into p lanes and each lane into four segments, letting p threads work a segment at a time. Lanes above the thread count you can actually schedule add synchronisation overhead without adding cost for the attacker.
Setting p higher than the cores you own slows your own logins while leaving attacker cost unchanged, and choosing p without checking the 8 × p memory minimum produces a configuration the library will simply reject.
This calculator takes 4 inputs: Physical CPU cores, Threads per core, Threads reserved for other work, Memory cost. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Not directly — total memory × passes is unchanged. But because p is recorded in the hash string, a verifier must be able to spawn p threads. Server deployments hashing many passwords at once usually set p=1 and rely on concurrency across requests instead.