On Thu, May 9, 2019 at 1:43 AM Ingo Molnar <mi...@kernel.org> wrote: > > > * Reshetova, Elena <elena.reshet...@intel.com> wrote: > > > > I find it ridiculous that even with 4K blocked get_random_bytes(), > > > which gives us 32k bits, which with 5 bits should amortize the RNG > > > call to something like "once per 6553 calls", we still see 17% > > > overhead? It's either a measurement artifact, or something doesn't > > > compute. > > > > If you check what happens underneath of get_random_bytes(), there is a > > fair amount of stuff that is going on, including reseeding CRNG if > > reseeding interval has passed (see _extract_crng()). It also even > > attempts to stir in more entropy from rdrand if avalaible: > > > > I will look into this whole construction slowly now to investigate. I > > did't optimize anything yet also (I take 8 bits at the time for > > offset), but these small optimization won't make performance impact > > from 17% --> 2%, so pointless for now, need a more radical shift. > > So assuming that the 17% overhead primarily comes from get_random_bytes() > (does it? I don't know), that's incredibly slow for something like the > system call entry path, even if it's batched. >
ISTM maybe a better first step would be to make get_random_bytes() be much faster? :) --Andy
