From: Thomas Gleixner <tglx@linutronix.de>
To: Adrian Hunter <adrian.hunter@intel.com>,
Peter Zijlstra <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
H Peter Anvin <hpa@zytor.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Leo Yan <leo.yan@linaro.org>, "jgross@suse.com" <jgross@suse.com>,
"sdeep@vmware.com" <sdeep@vmware.com>,
"pv-drivers@vmware.com" <pv-drivers@vmware.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"seanjc@google.com" <seanjc@google.com>,
"kys@microsoft.com" <kys@microsoft.com>,
"sthemmin@microsoft.com" <sthemmin@microsoft.com>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"Andrew.Cooper3@citrix.com" <Andrew.Cooper3@citrix.com>,
"Hall, Christopher S" <christopher.s.hall@intel.com>
Subject: Re: [PATCH V2 03/11] perf/x86: Add support for TSC in nanoseconds as a perf event clock
Date: Mon, 25 Apr 2022 11:32:15 +0200 [thread overview]
Message-ID: <87ilqx33vk.ffs@tglx> (raw)
In-Reply-To: <50fd2671-6070-0eba-ea68-9df9b79ccac3@intel.com>
On Mon, Apr 25 2022 at 08:30, Adrian Hunter wrote:
> On 14/03/22 13:50, Adrian Hunter wrote:
>>> TSC offsetting may also be a problem. The VMCS TSC offset must be discoverable by the
>>> guest. This can be done via TSC_ADJUST MSR. The offset in the VMCS and the guest
>>> TSC_ADJUST MSR must always be equivalent, i.e. a write to TSC_ADJUST in the guest
>>> must be reflected in the VMCS and any changes to the offset in the VMCS must be
>>> reflected in the TSC_ADJUST MSR. Otherwise a para-virtualized method must
>>> be invented to communicate an arbitrary VMCS TSC offset to the guest.
>>>
>>
>> In my view it is reasonable for perf to support TSC as a perf clock in any case
>> because:
>> a) it allows users to work entirely with TSC if they wish
>> b) other kernel performance / debug facilities like ftrace already support TSC
>> c) the patches to add TSC support are relatively small and straight-forward
>>
>> May we have support for TSC as a perf event clock?
>
> Any update on this?
If TSC is reliable on the host, then there is absolutely no reason not
to use it in the guest all over the place. And that is independent of
exposing ART to the guest.
So why do we need extra solutions for PT and perf, ftrace and whatever?
Can we just fix the underlying problem and make the hypervisor tell the
guest that TSC is stable, reliable and good to use?
Then everything else just falls into place and using TSC is a
substantial performance gain in general. Just look at the VDSO
implementation of __arch_get_hw_counter() -> vread_pvclock():
Instead of just reading the TSC, this needs to take a nested seqcount,
read TSC and do yet another mult/shift, which makes clock_gettime() ~20%
slower than necessary.
It's hillarious, that we still cling to this pvclock abomination, while
we happily expose TSC deadline timer to the guest. TSC virt scaling was
implemented in hardware for a reason.
Thanks,
tglx
next prev parent reply other threads:[~2022-04-25 9:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 11:09 [PATCH V2 00/11] perf intel-pt: Add perf event clocks to better support VM tracing Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 01/11] perf/x86: Fix native_perf_sched_clock_from_tsc() with __sched_clock_offset Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 02/11] perf/x86: Add support for TSC as a perf event clock Adrian Hunter
2022-03-04 12:30 ` Peter Zijlstra
2022-03-04 13:03 ` Adrian Hunter
2022-03-04 12:32 ` Peter Zijlstra
2022-03-04 17:51 ` Thomas Gleixner
2022-03-04 12:33 ` Peter Zijlstra
2022-03-04 12:41 ` Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 03/11] perf/x86: Add support for TSC in nanoseconds " Adrian Hunter
2022-03-04 13:41 ` Peter Zijlstra
2022-03-04 18:27 ` Adrian Hunter
2022-03-07 9:50 ` Peter Zijlstra
2022-03-07 10:06 ` Juergen Gross
2022-03-07 10:38 ` Peter Zijlstra
2022-03-07 10:58 ` Juergen Gross
2022-03-07 12:36 ` Adrian Hunter
2022-03-07 14:42 ` Peter Zijlstra
2022-03-08 14:23 ` Adrian Hunter
2022-03-08 21:06 ` Hall, Christopher S
2022-03-14 11:50 ` Adrian Hunter
2022-04-25 5:30 ` Adrian Hunter
2022-04-25 9:32 ` Thomas Gleixner [this message]
2022-04-25 13:15 ` Adrian Hunter
2022-04-25 17:05 ` Thomas Gleixner
2022-04-26 6:51 ` Adrian Hunter
2022-04-27 23:10 ` Thomas Gleixner
2022-05-16 7:20 ` Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 04/11] perf tools: Add new perf clock IDs Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 05/11] perf tools: Add API probes for new " Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 06/11] perf tools: Add new clock IDs to "perf time to TSC" test Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 07/11] perf tools: Add perf_read_tsc_conv_for_clockid() Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 08/11] perf intel-pt: Add support for new clock IDs Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 09/11] perf intel-pt: Use CLOCK_PERF_HW_CLOCK_NS by default Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 10/11] perf intel-pt: Add config variables for timing parameters Adrian Hunter
2022-02-14 11:09 ` [PATCH V2 11/11] perf intel-pt: Add documentation for new clock IDs Adrian Hunter
2022-02-21 6:54 ` [PATCH V2 00/11] perf intel-pt: Add perf event clocks to better support VM tracing Adrian Hunter
2022-03-01 11:06 ` Adrian Hunter
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=87ilqx33vk.ffs@tglx \
--to=tglx@linutronix.de \
--cc=Andrew.Cooper3@citrix.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=christopher.s.hall@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jolsa@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pv-drivers@vmware.com \
--cc=sdeep@vmware.com \
--cc=seanjc@google.com \
--cc=sthemmin@microsoft.com \
--cc=suzuki.poulose@arm.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
/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