linux-kernel - Re: [RFT/PATCH v2 2/6] x86-64: Optimize vread

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]

Message-ID: <20110407172832.GA13304@elte.hu>
Date:	Thu, 7 Apr 2011 19:28:32 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Andy Lutomirski <luto@....EDU>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFT/PATCH v2 2/6] x86-64: Optimize vread_tsc's barriers

* Andi Kleen <andi@...stfloor.org> wrote:

> > So the much better optimization would be to give up on exact GTOD coherency 
> > and just make sure the same task does not see time going backwards. If 
> > user-space wants precise coherency it can use synchronization primitives 
> > itsef. By default it would get the fast and possibly off by a few cycles 
> > thing instead. We'd never be seriously jump in time - only small jumps 
> > would happen in practice, depending on CPU parallelism effects.
> 
> That would be a big user visible break in compatibility.

Those are big scary words, but you really need to think this through:

Firstly, what is the user expectation? That a GTOD timestamp is provided. What 
will the user application do with that timestamp? Store it, for later use.

So there's implicit ordering all around these timestamps.

Secondly, x86 hardware never did a good job keeping our GTOD timestamps 
coherent, so while there *is* expectation for certainl behavior (Andy's for 
example), it's not widespread at all.

I bet that Linus's single-side barrier approach will be good enough in practice 
to meet Andy's needs. We might not be able to remove both barriers, but the 
tricks look really fragile ...

Andy, mind trying out Linus's suggestion? It should bring us more of a speedup 
and it would keep this code even simpler.

Thanks,

	Ingo
--
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/