[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1407220006470.20847@nanos>
Date: Tue, 22 Jul 2014 00:11:19 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andy Lutomirski <luto@...capital.net>
cc: Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>, x86-ml <x86@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] x86, TSC: Add a software TSC offset
On Tue, 22 Jul 2014, Thomas Gleixner wrote:
> On Mon, 21 Jul 2014, Andy Lutomirski wrote:
> > On Mon, Jul 21, 2014 at 2:52 PM, Borislav Petkov <bp@...en8.de> wrote:
> > > On Mon, Jul 21, 2014 at 02:41:50PM -0700, Andy Lutomirski wrote:
> > >> How will this be compatible with the vdso?
> > >
> > > I've never thought about it yet. How compatible would you want it to be
> > > and what do you expect from it?
> >
> > I expect that users of __vdso_clock_gettime (e.g. glibc) will get the
> > correct time :) They use vread_tsc, and they can't use
> > preempt_disable, because they're in userspace. They also can't
> > directly access per-cpu variables.
> >
> > Turning off vdso tsc support on these machines would be an option.
>
> Correct.
>
> So if we make the TSC usable that way we need to mark it unusable for
> the VDSO and force vdso_*gettime* into the kernel. That will be way
> better than forcing the whole machine onto HPET.
>
> And once we are using the real syscall, the whole thing just works ...
So all it needs is to do
clocksource_tsc.archdata.vclock_mode = VCLOCK_NONE;
if we do the magic per cpu offset trick to make the fcked up TSC
usable.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists