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