From: "Luck, Tony" <tony.luck@intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: Additional sampling fun
Date: Mon, 2 Mar 2020 17:03:51 -0800 [thread overview]
Message-ID: <20200303010351.GA26540@agluck-desk2.amr.corp.intel.com> (raw)
In-Reply-To: <87r1yefkfe.fsf@nanos.tec.linutronix.de>
On Fri, Feb 28, 2020 at 10:53:25PM +0100, speck for Thomas Gleixner wrote:
> 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.
The "Intel® Digital Random Number Generator (DRNG) Software Implementation Guide"[1]
provides graphs in section 3.4.1 showing that RDRAND throughput scales
linearly with the number of threads up to some saturation level (at
about 10 threads in the graph ... but the footnote says that these
results are "estimated" and "for informational purposes only").
I had thought that there was an RDSEED graph, but that must have been
in some internal document.
> So the question is whether the original RDSEED is slow already in the
> contended case or if the ucode mitigation will make it so.
If you plot throughput for RDSEED you'll get a flat line. Whatever
byte rate out got from one thread is all there is.
-Tony
[1] https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide
prev parent reply other threads:[~2020-03-03 1:03 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
2020-03-03 1:03 ` Luck, Tony [this message]
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=20200303010351.GA26540@agluck-desk2.amr.corp.intel.com \
--to=tony.luck@intel.com \
--cc=speck@linutronix.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).