historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: speck@linutronix.de
Subject: Re: Additional sampling fun
Date: Fri, 28 Feb 2020 22:53:25 +0100	[thread overview]
Message-ID: <87r1yefkfe.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200228180938.GA15113@agluck-desk2.amr.corp.intel.com>

speck for "Luck, Tony" <speck@linutronix.de> 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

  parent reply	other threads:[~2020-02-28 21:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 22:45 [MODERATED] [PATCH 0/2] more sampling fun 0 mark gross
2020-02-20  1:53 ` [MODERATED] " mark gross
2020-02-20  8:14 ` Greg KH
2020-02-20 14:27   ` Greg KH
2020-02-20 15:40     ` mark gross
2020-02-20 16:18       ` Greg KH
2020-02-20 14:55   ` Andi Kleen
2020-02-20 15:05     ` Greg KH
2020-02-20 16:55       ` Andi Kleen
2020-02-20 21:51     ` Josh Poimboeuf
2020-02-20 22:15       ` Andi Kleen
2020-02-20 22:59         ` Kees Cook
2020-02-20 15:09   ` mark gross
2020-02-28 16:21   ` [MODERATED] Additional sampling fun Borislav Petkov
2020-02-28 16:34     ` [MODERATED] " Greg KH
2020-02-28 17:38       ` mark gross
2020-02-28 17:44         ` Thomas Gleixner
2020-02-28 18:09           ` [MODERATED] " Luck, Tony
2020-02-28 18:40             ` Borislav Petkov
2020-02-28 21:53             ` Thomas Gleixner [this message]
2020-03-03  1:03               ` Luck, Tony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r1yefkfe.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=speck@linutronix.de \
    --subject='Re: Additional sampling fun' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).