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: <20080503163707.GA16644@elte.hu>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ