From: Ingo Molnar <mingo@kernel.org>
To: Yi Sun <yi.sun@intel.com>
Cc: dave.hansen@intel.com, tglx@linutronix.de,
linux-kernel@vger.kernel.org, x86@kernel.org,
sohil.mehta@intel.com, ak@linux.intel.com,
ilpo.jarvinen@linux.intel.com, heng.su@intel.com,
tony.luck@intel.com, dave.hansen@linux.intel.com,
yi.sun@intel.intel.com
Subject: Re: [PATCH v6 1/3] x86/fpu: Measure the Latency of XSAVES and XRSTORS
Date: Fri, 15 Sep 2023 11:54:44 +0200 [thread overview]
Message-ID: <ZQQp5LbMOHFJITkn@gmail.com> (raw)
In-Reply-To: <ZPg8pJR55pmEZ4vQ@ysun46-mobl.ccr.corp.intel.com>
* Yi Sun <yi.sun@intel.com> wrote:
> > Instead of adding overhead to the regular FPU context saving/restoring
> > code paths, could you add a helper function that has tracing code
> > included, but which isn't otherwise used - and leave the regular code
> > with no tracing overhead?
> Furthermore, according doc static-keys.txt, the condition
> xrstor_tracing_enabled() would introduce only a minimal overhead when the
> trace is disabled. I believe it is a negligible impact on the performance
> when the trace is disabled.
Why introduce *any* extra overhead if it's possible to test the
functionality separately? The stated goal of the series is only to measure
FPU context switch performance, which doesn't require extra added overhead
to the actual context switch path.
[ Or if you want to convince reviewers that the overhead is indeed minimal,
please provide before/after generated assembly of the affected code that
demonstrates minimal impact. ]
Thanks,
Ingo
next prev parent reply other threads:[~2023-09-15 9:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 14:34 [PATCH v6 0/3] x86/fpu Measure the Latency of XSAVES and Yi Sun
2023-09-01 14:34 ` [PATCH v6 1/3] x86/fpu: Measure the Latency of XSAVES and XRSTORS Yi Sun
2023-09-02 10:49 ` Ingo Molnar
2023-09-02 19:09 ` Andi Kleen
2023-09-06 9:18 ` Yi Sun
2023-09-06 18:49 ` Dave Hansen
2023-09-06 22:02 ` Ingo Molnar
2023-09-08 0:24 ` Yi Sun
2023-09-06 8:47 ` Yi Sun
2023-09-15 9:54 ` Ingo Molnar [this message]
2023-09-01 14:34 ` [PATCH v6 2/3] tools/testing/fpu: Add script to consume trace log of xsaves latency Yi Sun
2023-09-01 14:34 ` [PATCH v6 3/3] tools/testing/fpu: Add a 'count' column 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=ZQQp5LbMOHFJITkn@gmail.com \
--to=mingo@kernel.org \
--cc=ak@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=heng.su@intel.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=yi.sun@intel.com \
--cc=yi.sun@intel.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;
as well as URLs for NNTP newsgroup(s).