On Mon, Jul 23, 2012 at 5:14 PM, Linus Walleij <linus.wall...@linaro.org> wrote: > 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.)
There's a comment somewhere about higher resolution sched_clock providing fairer scheduling. With 32 kHz sched_clock, every runtime measured by the scheduler will be wrong by up to 31.25 us. Most systems have a faster clock, and if it's available it seems silly not to use it. It's also used for tracing, where 31.25 us resolution is a little low for function tracing or function graph tracing. >> 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 sched_clock is supposed to be very low overhead compared to ktime_get, and has some strict requirements if CONFIG_HAVE_UNSTABLE_SCHED_CLOCK is not set (see kernel/sched/clock.c), but it might be possible. -- 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/
