[bodyfour]

Yeah basically. That could be a disaster for, say, nonce generation.

The solution would be to have multiple independent entropy pools and either bind them to cores(/sets of cores) or pick a non-busy one in a contention case.

[acqq]

Yes, if there is no a urandom generator per core, it would be convenient for some extreme cases to introduce such. The question is if it's worth the effort and the resulted "bloat" of the kernel code and memory usage. Linux runs on some very small devices too and even there decent user-space programmers can easily do their own per-thread generation in their programs. Normal uses of crypto are such: you initialize your own crypto once, then produce a lot of data in your own space.

If urandom is really "one for all cores" somebody should be able to demonstrate the speed drop by just writing some bash script? Volunteers?

[claudius]

It seems to work in part. For /dev/urandom, I see always roughly the same throughput:

  $ time dd if=/dev/urandom of=/dev/null bs=1 count=10000000
  real	0m10.640s
  user	0m0.696s
  sys	0m9.940s

  $ time (for i in $(seq 1 50); do dd if=/dev/urandom of=/dev/null bs=1 count=200000 2>/dev/null & done; wait)
  real	0m11.199s
  user	0m1.232s
  sys	0m42.828s

  $ time (for i in $(seq 1 500); do dd if=/dev/urandom of=/dev/null bs=1 count=20000 2>/dev/null & done; wait)
  real	0m11.234s
  user	0m1.252s
  sys	0m42.536s

whereas for /dev/zero:

  $ time dd if=/dev/zero of=/dev/null bs=1 count=10000000
  real	0m3.268s
  user	0m0.660s
  sys	0m2.604s

  $ time (for i in $(seq 1 50); do dd if=/dev/zero of=/dev/null bs=1 count=200000 2>/dev/null & done; wait)
  real	0m2.550s
  user	0m1.192s
  sys	0m8.760s

  $ time (for i in $(seq 1 500); do dd if=/dev/zero of=/dev/null bs=1 count=20000 2>/dev/null & done; wait)
  real	0m2.612s
  user	0m1.228s
  sys	0m8.112s

Of course, the bash for-loop here together with the forking has some considerable overhead, so these values should likely be interpreted carefully (Linux 3.14-rc7, Core i5 520M).