linux-kernel - Re: [RFC][PATCH] sched_clock

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, 3 May 2008 18:37:07 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	David Miller <davem@...emloft.net>,
	Guillaume Chazarain <guichaz@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	Mike Galbraith <efault@....de>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH] sched_clock_cpu()

* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> Hi,
> 
> This is my current proposal to replace the rq->clock stuff (and 
> possibly cpu_clock()).
> 
> it _DOESN'T_ boot ;-/ and I seem to have caught a flu that makes my 
> whole body hurt like hell, so I'm not getting anything done.

ouch - getter better soon!

> Brain dump before I crash:
> 
>  - architectures that have a 'perfect' hardware clock can set
>      CONFIG_HAVE_STABLE_CLOCK

ok.

>  - the 'jiffie' window might be superfulous when we update tick_gtod
>    before the __update_sched_clock() call in sched_clock_tick()
> 
>  - cpu_clock() might be implemented as:
> 
>      sched_clock_cpu(smp_processor_id())
> 
>    if the accuracy proves good enough - how far can TSC drift in a
>    single jiffie when considering the filtering and idle hooks?

it 'can' be very bad - so we have to assume it's random and fall back to 
jiffies quality in that case. In practice on most x86 CPUs it wont drift 
that far - even drifting TSCs drift minimally (there are AMD 
Athlon64/Opteron CPUs where a CPU in HLT will cause the clock and the 
TSC to drift a bit) - and stopping TSCs will just stop.

But in terms of BIOSes trying to fix things up and in terms of cpufreq 
artifacts (the CPU's clock itself going through transients) anything can 
happen and the code must be robust.

>  - what other architectures besides x86 would need this?

we rarely get any interactivity reports from anything non-x86 so i doubt 
it truly matters on anything but x86. If it _breaks_ in terms of 
crashing or locking we do hear from other architectures ;-)

	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/