Messages in this thread | | | Date | 13 Oct 2015 17:10:30 -0400 | From | "George Spelvin" <> | Subject | Re: Updated scalable urandom patchkit |
| |
> Ted's patch peaks at 350K with four CPUs, but then quickly degrades to > 50K ops/s at 20+ CPUs. At 144 CPUs it is slightly faster again at ~80K.
Good to know, thanks! With its race conditions, it's basically a "best case" for that particular design, which tells me that more significant changes are required.
Off hand, do you know how large a read each operation is? I want to reduce mixback from once per 10 bytes to once per read, and the size ratio will give me some idea of how large an improvement to expect.
> Spelvin's patch peaks at only 140K at 2 CPUs (so it's slower than base line), > stays around 120K upto 20, then degrades quickly to 50K and then slowly > improves again to ~80K.
Sorry to make you go to the trouble; I knew from discussions with Ted that it wasn't going to work. It was mostly just in the form of a patch for the sake of a more concrete discussion.
I'll have a patch that I hope will do some good for testing in a couple of hours.
> The duplicated pool patch is ~200K upto 20 CPus, 400K upto 40, 600K at > slightly below 60 CPUs, and then very slowly degrades to 520K at 144.
Shitty performance is practically a design goal of /dev/urandom. You are NOT supposed to hit it more than once per minute per thread.
But since we have a real-world problem with it, Ted's "abusse mitigation mode" idea (where the kernel does what the app should do: seed a private CPRNG and use that) will provide good security at extremely high access rates.
| |