On Mon, Jul 23, 2012 at 9:27 PM, Colin Cross <ccr...@android.com> 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 sched_clock() implemented. 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. OK agreed. 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 Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
