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: <200702011345.14708.ak@suse.de>
Date:	Thu, 1 Feb 2007 13:45:14 +0100
From:	Andi Kleen <ak@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
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

On Thursday 01 February 2007 13:24, Ingo Molnar wrote:

> 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 would be better to let the application set it without root rights 
(afaik W. allows this).  Auto tuning beats explicit configuration anytime.

Not sure it's really worth it though.

My thinking was to gather more requirements of what users actually
want first before adding all these new modi.

> [ 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. ]

zmailer used to do that (or probably still does) but I always hated
the scheme for some reason :)


> > [...] 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.

Good point. Even on desktop with Multi Core or SMT it should be cheaper now.

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