linux-kernel - Re: [RFC][PATCH 5/7] x86: Use latch data structure for cyc2ns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 30 Nov 2013 10:18:47 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Eliezer Tamir <eliezer.tamir@...ux.intel.com>,
	John Stultz <john.stultz@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...e.hu>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tony Luck <tony.luck@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC][PATCH 5/7] x86: Use latch data structure for cyc2ns

On Fri, Nov 29, 2013 at 03:22:45PM -0800, Andy Lutomirski wrote:
> On Fri, Nov 29, 2013 at 9:37 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > Use the 'latch' data structure for cyc2ns.
> >
> > This is a data structure first proposed by me and later named by
> > Mathieu. If anybody's got a better name; do holler.
> 
> That structure must exist in the literature, but I have no idea what
> it's called.  It's a multi-word lock-free atomic (I think -- maybe
> it's just regular) register.  I even published a considerably fancier
> version of much the same thing a few years ago.  :)

Yeah, its a fairly straight fwd thing it has to be named someplace ;-)

> I've occasionally wondered whether it would be possible to make a
> monotonicity-preserving version of this and use it for clock_gettime.
> One approach: have the writer set the time for the update to be a bit
> in the future and have the reader compare the current raw time to the
> cutoff to see which set of frequency/offset to use.  (This requires
> having some kind of bound on how long it takes to update the data
> structures.)
> 
> The advantage: clock_gettime would never block.
> The disadvantage: complicated, potentially nasty to implement, and it
> would get complicated if anyone tried to allow multiple updates in
> rapid succession.

Yes, that way you can chain a number of linear segments in various
slots, but you're indeed right in that it will limit the update
frequency. More slots will give you more room, but eventually you're
limited.

I suppose NTP is the primary updater in that case, does that have a
limit on the updates? All the other updates we can artificially limit,
that shouldn't really matter.

But yeah in my case we pretty much assume the TSC is complete crap and a
little more crap simply doesn't matter.

For the 'stable' tsc on modern machines we never set the frequency and
it doesn't matter anyway.
--
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/