lkml.org 
[lkml]   [2012]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC] ARM: sched_clock: update epoch_cyc on resume
    From
    On Mon, Jul 23, 2012 at 5:14 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
    > On Mon, Jul 23, 2012 at 9:27 PM, Colin Cross <ccross@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.


    \
     
     \ /
      Last update: 2012-07-24 03:01    [W:0.035 / U:63.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site