Re: [RFC] ARM: sched_clock: update epoch_cyc on resume
From: Linus Walleij
Date: Mon Jul 23 2012 - 20:15:10 EST
On Mon, Jul 23, 2012 at 9:27 PM, Colin Cross <ccross@xxxxxxxxxxx> wrote:
> On Mon, Jul 23, 2012 at 11:55 AM, Linus Walleij
> Does the clock you use for sched_clock continue to run in all suspend
> modes? All the SoC's I've used only have a 32kHz clock in the deepest
> suspend mode,
Yes, and yes it is 32kHz.
> which is not ideal for sched_clock.
Not that I know why scheduling with 32kHz is so bad compared to the
default system scheduling granularity which is HZ if you don't have
Since this seems to be such an important point, what makes you
want MHz:es for scheduling granularity? To me the biggest impact
is actually the granularity of the timestamps in the printk:s.
(It's not that I doubt your needs, more curiosity.)
> For example, on
> Tegra2 the faster 1MHz clock used for sched_clock resets in the
> deepest suspend state (LP0) but not the shallowest suspend state
> (LP2), and which suspend state the chip hits depends on which hardware
> is active. Opting out of this patch would cause Tegra's clock to
> sometimes run in suspend, and sometimes not, which seems worse for
> debugging than consistently not running in suspend. I'd be surprised
> if a similar situation didn't apply to your platform.
Well being able to switch between different sched_clock() providers
may be the ideal...
>> - If it absolutely needs to be in the core code, also have a bool
>> field indicating whether the clock is going to die during suspend
>> and add new registration functions for setting that sched_clock
>> type, e.g. setup_sched_clock_nonsuspendable()
> Sounds reasonable if some platforms need the extra complexity.
A connecting theme is that of being avle to flag clock sources as
sched_clock providers. If all clocksources were tagged with
rating, and only clocksources were used for sched_clock(), the
kernel could select the highest-rated clock under all circumstances.
But that's quite intrusive, more of an idea. :-P
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/