[MODERATED] Re: Additional sampling fun

On Fri, Feb 28, 2020 at 06:44:48PM +0100, speck for Thomas Gleixner wrote:
> speck for mark gross <[email protected]> writes:
> > On Fri, Feb 28, 2020 at 05:34:47PM +0100, speck for Greg KH wrote:
> >> On Fri, Feb 28, 2020 at 05:21:40PM +0100, speck for Borislav Petkov wrote:
> >> Ugh.  I think we need to drag Jason into this as well, but really,
> >> talking about that can be done on the mailing list as there's nothing
> >> wrong with trying to get that slow code out of the irq path today,
> >> right?
> >> 
> > FWIW unless someone is abusing rdrand/rdseed I don't think the impact of the
> > mitigation will be measurable.  Running multiple instances of spanking rdrand
> > in a loop will show nonlinear impacts due to bus lock contention but, I don't
> > think there is any contention issues with once/64IRS's or once a second.  you
> > are looking at approximately O(100cycles) vrs O(1000cycles) every second or
> > every 64th interrupt.  I don't think you'll be able to measure the impact of
> > that.  (unless you force lock contention on the HW bus lock)
> 
> 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).

-Tony