Re: Additional sampling fun

speck for "Luck, Tony" <[email protected]> writes:
> On Fri, Feb 28, 2020 at 06:44:48PM +0100, speck for Thomas Gleixner wrote:
>> Have several cores with a 10k+ interrupts per second and if you're
>> unlucky they start to contend, then the every 64th interrupt will be
>> measurable quite prominent.
>> 
>> But I agree with Greg, that we can tackle this on LKML without
>> mentioning that particular issue.
>
> That code really shouldn't ever have been using RDSEED (which is documented
> as NOT scaling across invocations on multiple cores).

The only thing what the SDM says is:

  Under heavy load, with multiple cores executing RDSEED in parallel, it
  is possible for the demand of random numbers by software
  processes/threads to exceed the rate at which the random number
  generator hardware can supply them. This will lead to the RDSEED
  instruction returning no data transitorily. The RDSEED instruction
  indicates the occurrence of this situation by clearing the CF flag.

I does not tell that it's slow to return CF=0. And if it does the
current code just ignores it and carries on.

So the question is whether the original RDSEED is slow already in the
contended case or if the ucode mitigation will make it so.

Thanks,

        tglx