[MODERATED] Re: [PATCH 0/2] more sampling fun 0

On Thu, Feb 20, 2020 at 03:51:32PM -0600, speck for Josh Poimboeuf wrote:
> On Thu, Feb 20, 2020 at 06:55:10AM -0800, speck for Andi Kleen wrote:
> > > Then we need to stop using RDRAND internally for our "give me a random
> > > number api" which has spread to more and more parts of the kernel.
> > 
> > Only if that API is called frequently enough. AFAIK it is not. 
> > 
> > Normally it's used for rare rekeying of hash tables etc., which
> > doesn't happen very often.
> > 
> > > Here's a patch that does so:
> > > 	https://lore.kernel.org/lkml/[email protected]/
> > > which I'm going to advise get merged now and backported to the stable
> > > branches.
> > 
> > Don't see any reason at this point. Only do it if there's an actual
> > indication of a problem.
> 
> Internal testing of the SRBDS beta microcode on Kaby Lake is showing
> significant slowdowns in several syscall microbenchmarks.
> 
> One pthread_create() microbenchmark had a ~48% slowdown.  We confirmed
> it was due to RDRAND in get_random_u64().
> 
> In this case I think the path was:
> 
>  clone()
>    _do_fork()
>      copy_process()
>        dup_task_struct()
>          get_random_canary() (due to CONFIG_STACKPROTECTOR)
> 	   get_random_long()
> 	     get_random_u64()
> 	       arch_get_random_long()
> 	         RDRAND

Okay thanks, then we need the patch Greg pointed out.

-Andi