linux-kernel - Re: [-mm patch] x86_64 GTOD: offer scalable vgettimeofday II

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: <20070201122433.GA5255@elte.hu>
Date:	Thu, 1 Feb 2007 13:24:33 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <ak@...e.de>
Cc:	jbohac@...e.cz, linux-kernel@...r.kernel.org,
	Vojtech Pavlik <vojtech@...e.cz>, arjan@...radead.org,
	tglx@...utronix.de, johnstul@...ibm.com,
	Andrew Morton <akpm@...l.org>
Subject: Re: [-mm patch] x86_64 GTOD: offer scalable vgettimeofday II

* Andi Kleen <ak@...e.de> wrote:

> > The 'price' paid for it is lower resolution - but it's still good 
> > for those benchmarking TPC-C runs - and /alot/ simpler.
> 
> BTW another comment: I was told that at least one of the big databases 
> wants ms resolution here. So to make your scheme work would require a 
> HZ=1024 regular interrupt. [...]

if resolution is an issue then i can improve this thing to be based off 
a separate /optional/ hrtimer, thus if it's enabled it could enable 1000 
Hz (and not 1024 Hz) update for the variable. The update resolution 
could be tuned via a sysctl trivially, so everyone could tune the 
resolution of this to the value desired, and could do so runtime.

[ It could also be driven by the database right now: from a thread open 
  /dev/rtc, set it to 1024 HZ, and do a gettimeofday() call in every 
  tick - that will auto-update the timestamp. ]

> [...] But that would also make everything slower again due to CPU 
> overhead as it was learned in the 2.4->2.6 HZ transition.

note that this cost was measured on UP and on older hardware, and the 
cost of having a global 1000 Hz update gets linearly cheaper with the 
increase of CPUs on SMP: because only one such update has to be running. 
The systems those database vendors are interested in typically have a 
fair number of CPUs.

	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/