The problem seems to be that AMD somehow can’t generate long type RDRAND
(which afaik, is an instruction that Intel suggested/implemented)
fast enough.
The patch suggests to use arch_get_random_int() instead of arch_get_random_long().
But we can avoid patching kernel by just simply avoiding RDRAND altogether.
Imo, the Linux kernel has a poor implementation of getting random entropy from RDRAND.
Both my Intel and AMD systems can now do 330+ MB/s by appending “nordrand” to cmdline.
RDRAND should be an additional entropy source, rather than slowing it down.
Linux kernel should have an asynchronous design to read RDRAND, imo.
But until then, I suggest everyone(maybe even Intel) to use “nordrand” to cmdline.
On an Intel Core i7-7700K, 4500 MHz (45 x 100MHz) processor (Kaby Lake-S microarchitecture), a single RDRAND or RDSEED instruction takes 110ns or 463 clock cycles, regardless of the operand size (16/32/64 bits). This number of clock cycles applies to all processors with Skylake or Kaby Lake microarchitecture. On the Silvermont microarchitecture processors, each of the instructions take around 1472 clock cycles, regardless of the operand size; and on Ivy Bridge processors it takes up to 117 clock cycles[18].
On an AMD Ryzen CPU, each of the instructions takes around 1200 clock cycles for 16-bit or 32-bit operand, and around 2500 clock cycles for a 64-bit operand.
and even cooler is when you read about Linus and Linux.
Linus Torvalds dismissed concerns about the use of RdRand in the Linux kernel, and pointed out that it is not used as the only source of entropy for /dev/random, but rather used to improve the entropy by combining the values received from RdRand with other sources of randomness.[25][26] However, Taylor Hornby of Defuse Security demonstrated that the Linux random number generator could become insecure if a backdoor is introduced into the RdRand instruction that specifically targets the code using it. Hornby’s proof-of-concept implementation works on an unmodified Linux kernel prior to version 3.13
[mdesilva@i9-7920X ~]$ time head -c 1G /dev/urandom > /dev/null
real 0m4.580s
user 0m0.017s
sys 0m4.558s
# 1950X... ouch
[mdesilva@ballinripper ~]$ time head -c 1G /dev/urandom > /dev/null │················
│················
real 0m14.794s │················
user 0m0.026s │················
sys 0m14.736s
My i5-7500U (dual core) laptop is between 150 MB/s and 180 MB/s with a single SATA SSD.
Are you sure it’s not a chipset or storage controller issue?
Isn’t /dev/null still on the root partition?
Try making the comparison with the same SSD in both computers. If you can, compare an m.2 and single SATA or even stripe-RAID SATA to see the difference.
The last time I rebuilt one of the computers in my family, I went with a cheap unlocked dual core Pentium and just put a pair of cheap SSD’s in a stripe RAID because power consumption was the main concern.
It’s still running perfectly fine at 4.2 GHz with no complaints and one of the most power-efficient computers I support.
