From: Thomas Gleixner <tglx@linutronix.de>
To: Jason Vas Dias <jason.vas.dias@gmail.com>
Cc: kernel-janitors@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Prarit Bhargava <prarit@redhat.com>,
x86@kernel.org
Subject: Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609
Date: Wed, 22 Feb 2017 11:53:33 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.20.1702220958590.3782@nanos> (raw)
In-Reply-To: <CALyZvKyTGOmXC9DxcS-UR-STSwtJONMQA6srtZAaiLURcOxqvA@mail.gmail.com>
On Wed, 22 Feb 2017, Jason Vas Dias wrote:
> Yes, my CPU is still getting a fault every time the TSC_ADJUST MSR is
> read or written . It is probably because it genuinuely does not support
> any cpuid > 13 , or the modern TSC_ADJUST interface.
Err no. TSC_ADJUST is available when CPUID(70 EBX has bit 1 set.
Please provide the output of:
# cpuid -1 -r
for that machine
> This is probably why my clock_gettime() latencies are so bad. Now I have
> to develop a patch to disable all access to TSC_ADJUST MSR if
> boot_cpu_data.cpuid_level <= 13 . I really have an unlucky CPU :-) .
Can you just try to boot linux 4.10 on that machine an report whether it
works? It will touch the TSC_ADJUST MRS when the feature bit is set.
> But really, I think this issue goes deeper into the fundamental limits of
> time measurement on Linux : it is never going to be possible to measure
> minimum times with clock_gettime() comparable with those returned by
> rdtscp instruction - the time taken to enter the kernel through the VDSO,
> queue an access to vsyscall_gtod_data via a workqueue, access it & do
> computations & copy value to user-space
Sorry, that's not how the VDSO works. It does not involve workqueues, copy
to user space and whatever. VDSO is mapped into user space and only goes
into the when TSC is not working or the VDSO access is disabled or you want
to access a CLOCKID which is not supported in the VDSO.
> is NEVER going to be up to the job of measuring small real-time durations
> of the order of 10-20 TSC ticks .
clock_gettime(CLOCK_MONOTONIC) via VDSO takes ~20ns on my haswell laptop
> I think the best way to solve this problem going forward would be to store
> the entire vsyscall_gtod_data data structure representing the current
> clocksource
> in a shared page which is memory-mappable (read-only) by user-space .
This is what VDSO does. It provides the data R/O to user space and it also
provides the accessor functions.
CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_MONOTONIC_COARSE and
CLOCK_REALTIME_COARSE are handled in the VDSO (user space) and never enter
the kernel.
I really have a hard time to understand what you are trying to solve.
Thanks,
tglx
next prev parent reply other threads:[~2017-02-22 19:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-19 0:31 Jason Vas Dias
2017-02-19 15:35 ` Jason Vas Dias
2017-02-20 21:49 ` Thomas Gleixner
2017-02-21 23:39 ` Jason Vas Dias
2017-02-22 16:07 ` Jason Vas Dias
2017-02-22 16:18 ` Jason Vas Dias
2017-02-22 17:27 ` Jason Vas Dias
2017-02-22 19:53 ` Thomas Gleixner [this message]
2017-02-22 20:15 ` Jason Vas Dias
2017-02-22 20:26 ` Jason Vas Dias
2017-02-23 18:05 ` Jason Vas Dias
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=alpine.DEB.2.20.1702220958590.3782@nanos \
--to=tglx@linutronix.de \
--cc=hpa@zytor.com \
--cc=jason.vas.dias@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=prarit@redhat.com \
--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
all inboxes | Powered by JetHome®