mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: David Laight <David.Laight@ACULAB.COM>,
	'Yi Sun' <yi.sun@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Cc: "sohil.mehta@intel.com" <sohil.mehta@intel.com>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"heng.su@intel.com" <heng.su@intel.com>
Subject: Re: [PATCH 1/2] x86/fpu: Measure the Latency of XSAVE and XRSTOR
Date: Mon, 25 Jul 2022 10:44:23 -0700	[thread overview]
Message-ID: <f2a0e0e0-79f2-1b5c-2bcd-b6037d479d4e@intel.com> (raw)
In-Reply-To: <921078bc2a994d3ab6aba26d4654cb47@AcuMS.aculab.com>

On 7/24/22 13:54, David Laight wrote:
> I've done some experiments that measure short instruction latencies.
> Basically I found:

Short?  The instructions in question can write up to about 12k of data.
 That's not "short" by any means.

I'm also not sure precision here is all that important.  The main things
we want to know here when and where the init and modified optimizations
are coming into play.  In other words, how often is there actual data
that *needs* to be saved and restored and can't be optimized away.

So, sure, if we were measuring a dozen cycles here, you could make an
argument that this _might_ be problematic.

But, in this case, we really just want to be able to tell when
XSAVE/XRSTOR are getting more or less expensive and also get out a
minimal amount of data (RFBM/XINUSE) to make a guess why that might be.

Is it *REALLY* worth throwing serializing instructions in and moving
clock sources to do that?  Is the added precision worth it?

  parent reply	other threads:[~2022-07-25 17:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-23  8:37 [PATCH 0/2] x86: Add xsave/xrstor Latency Trace Events and Consuming Script Yi Sun
2022-07-23  8:37 ` [PATCH 1/2] x86/fpu: Measure the Latency of XSAVE and XRSTOR Yi Sun
2022-07-24 20:54   ` David Laight
2022-07-24 23:00     ` Luck, Tony
2022-07-25  7:35       ` David Laight
2022-07-25 17:44     ` Dave Hansen [this message]
2022-07-26  7:41       ` David Laight
2022-07-26  9:03     ` 'Yi Sun'
2022-07-28 18:46   ` Sohil Mehta
2022-07-23  8:38 ` [PATCH 2/2] scripts/x86: Add script to consume trace log of xsave latency Yi Sun

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=f2a0e0e0-79f2-1b5c-2bcd-b6037d479d4e@intel.com \
    --to=dave.hansen@intel.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=heng.su@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sohil.mehta@intel.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yi.sun@intel.com \
    /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
all inboxes | Powered by JetHome®