historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: Additional sampling fun
Date: Fri, 28 Feb 2020 10:09:38 -0800	[thread overview]
Message-ID: <20200228180938.GA15113@agluck-desk2.amr.corp.intel.com> (raw)
In-Reply-To: <87zhd2fvxr.fsf@nanos.tec.linutronix.de>

On Fri, Feb 28, 2020 at 06:44:48PM +0100, speck for Thomas Gleixner wrote:
> speck for mark gross <speck@linutronix.de> 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

  reply	other threads:[~2020-02-28 18:09 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           ` Luck, Tony [this message]
2020-02-28 18:40             ` [MODERATED] " Borislav Petkov
2020-02-28 21:53             ` Thomas Gleixner
2020-03-03  1:03               ` [MODERATED] " 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=20200228180938.GA15113@agluck-desk2.amr.corp.intel.com \
    --to=tony.luck@intel.com \
    --cc=speck@linutronix.de \
    --subject='[MODERATED] 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).