Hi Andy,

On Fri, Aug 07, 2020 at 10:55:11AM -0700, Andy Lutomirski wrote:

...

...

This is still another non-cryptographic PRNG.

Absolutely. During some discussions regarding the possibility of using CSPRNGs, orders around hundreds of CPU cycles were mentioned for them, which can definitely be a huge waste of precious resources for some workloads, possibly causing the addition of a few percent extra machines in certain environments just to keep the average load under a certain threshold.

I think the real random.c can run plenty fast. It's ChaCha20 plus ludicrous overhead right now. I'm working (slowly) on making the overhead go away. I'm hoping to have something testable in a few days. As it stands, there is a ton of indirection, a pile of locks, multiple time comparisons, per-node and percpu buffers (why both?), wasted bits due to alignment, and probably other things that can be cleaned up. I'm trying to come up with something that is fast and has easy-to-understand semantics.

You can follow along at:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=random...

Thanks, we'll see. I developed a quick test tool that's meant to be easy to use to measure the performance impact on connect/accept. I have not yet run it on a modified PRNG to verify if it works. I'll send it once I've tested. I'd definitely would like to see no measurable performance drop, and ideally even a small performance increase (as Tausworthe isn't the lightest thing around either so we do have some little margin).

Willy