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 21:53:27 -0000 Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j7nZW-0006vr-Sx for speck@linutronix.de; Fri, 28 Feb 2020 22:53:26 +0100 From: Thomas Gleixner Subject: Re: Additional sampling fun In-Reply-To: <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> <20200228180938.GA15113@agluck-desk2.amr.corp.intel.com> Date: Fri, 28 Feb 2020 22:53:25 +0100 Message-ID: <87r1yefkfe.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: speck for "Luck, Tony" 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