One of these things (CONFIG_HZ) is not like the others..

[Matt Sealey]

On Mon, Jan 21, 2013 at 7:18 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Jan 21, 2013 at 07:06:59PM -0600, Matt Sealey wrote:
>> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz <john.stultz at linaro.org> wrote:
>> > On 01/21/2013 02:54 PM, Matt Sealey wrote:
>
> sched_clock() has nothing to do with time keeping, and that
> HZ/NO_HZ/HRTIMERS don't affect it (when it isn't being derived from
> jiffies).
>
> Now, sched_clock() is there to give the scheduler a _fast_ to access,
> higher resolution clock than is available from other sources, so that
> there's ways of accurately measuring the amount of time processes run
> for,

That depends on what you meant by timekeeping, right?

I'm really not concerned about the wallclock time, more about the
accuracy of the scheduler clock (tick?), preemption, accurate delays
(i.e. if I msleep(10) does it delay for 10ms or for 40ms because my
delay timer is inaccurate? I'd rather it was better but closer to
10ms), and whether the scheduler (the thing that tells my userspace
whether firefox is running now, or totem, or any other task) is using
the correct high resolution periodic, oneshot, repeatable (however it
repeats) timers *properly* given that this magic config item is
missing on ARM.

That magic config item being CONFIG_SCHED_HRTICK which is referenced a
bunch in kernel/sched/*.[ch] but *ONLY* defined as a Kconfig item in
kernel/Kconfig.hz.

Do we need to copy that Kconfig item out to arch/arm/Kconfig, that's
the question?

>  and other such measurements - and it uses that to determine how
> to schedule a particular task and when to preempt it.
>
> Not providing it means you get those measurements at HZ-based resolution,
> which is suboptimal for tasks which run often for sub-HZ periods (which
> can end up accumulating zero run time.)

Okay, and John said earlier:

John Stultz:
> So I'm actually not super familiar with SCHED_HRTICK details, but from my
> brief skim of it it looks like its useful for turning off the periodic timer
> tick, and allowing the scheduler tick to be triggered by an hrtimer itself
> (There's a number of these interesting inversions that go on in switching to
> HRT mode - for instance, standard timer ticks are switched to being hrtimer
> events themselves).
>
> This likely has the benefit of time-accurate preemption (well, long term, as
> if the timer granularity isn't matching you could be delayed up to a tick -
> but it wouldn't drift).
>
> I'm guessing Thomas would probably know best what the potential issues would
> be from running ((CONFIG_HRTIMER  || CONFIG_NO_HZ) && !CONFIG_SCHED_HRTICK).

If SCHED_HRTICK isn't enabled but setup_sched_clock has been given an
accessor for a real, hardware, fast, high resolution counter that
meets all the needs of sched_clock, what's going on? If it's enabled,
what extra is it doing that, say, my_plat_read_sched_clock doesn't?

--
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.