> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
