From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 28 Feb 2020 18:09:47 -0000 Received: from mga09.intel.com ([134.134.136.24]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j7k54-0004JH-7b for speck@linutronix.de; Fri, 28 Feb 2020 19:09:47 +0100 Date: Fri, 28 Feb 2020 10:09:38 -0800 From: "Luck, Tony" Subject: [MODERATED] Re: Additional sampling fun Message-ID: <20200228180938.GA15113@agluck-desk2.amr.corp.intel.com> References: <20200220081420.GA3328448@kroah.com> <20200228162140.GB24511@zn.tnic> <20200228163447.GA3241225@kroah.com> <20200228173845.GA2466@mtg-dev.jf.intel.com> <87zhd2fvxr.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 In-Reply-To: <87zhd2fvxr.fsf@nanos.tec.linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Feb 28, 2020 at 06:44:48PM +0100, speck for Thomas Gleixner wrote: > speck for mark gross 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