[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28c575e4-daa1-a959-e9a5-20f05033a6f0@oracle.com>
Date: Wed, 27 Sep 2017 13:10:35 -0400
From: Pasha Tatashin <pasha.tatashin@...cle.com>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
john.stultz@...aro.org, sboyd@...eaurora.org, x86@...nel.org,
linux-kernel@...r.kernel.org, mingo@...hat.com,
peterz@...radead.org, tglx@...utronix.de, hpa@...or.com,
douly.fnst@...fujitsu.com, Peter Zijlstra <peterz@...radead.org>,
Dou Liyang <douly.fnst@...fujitsu.com>
Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early
in boot
Hi Russell,
This might be so for ARM, and in fact if you look at my SPARC
implementation, I simply made source clock initialize early, so regular
sched_clock() is used. As on SPARC, we use either %tick or %stick
registers with frequency determined via OpenFrimware. But, on x86 there
are dozen ways clock sources are setup, and some of them available quiet
late in boot because of various dependencies. So, my early clock
initialization for x86 (and expendable to other platforms with unstable
clocks) is to make it available when TSC is available, which is
determined by already existing kernel functionality in
simple_udelay_calibration().
My goal was not to introduce any regressions to the already complex (in
terms of number of branches and loads) sched_clock_cpu(), therefore I
added a new function and avoided any extra branches through out the life
of the system. I could mitigate some of that by using static branches,
but imo the current approach is better.
Pasha
Powered by blists - more mailing lists