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/fast 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
