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

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

-- 
Josh