lkml.org 
[lkml]   [2009]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] sched: Support current clocksource handling in fallback sched_clock().
    On Wed, 27 May 2009, Paul Mundt wrote:
    > > Yea. So this is a little better. There's still a few other issues to
    > > consider:
    > >
    > > 1) What if a clocksource is registered that has the _SCHED_CLOCK bit
    > > set, but is not selected for timekeeping due it being unstable like the
    > > TSC?
    > >
    > See, this is what I thought the rating information was useful for, as the
    > rating is subsequently dropped if it is not usable. But perhaps it makes
    > more sense to just clear the bit at the same time that the rating is
    > lowered once it turns out to be unstable.

    Stop worrying about TSC please. The x86 f*cked up timers need special
    handling which is definitely not required for most of arch/*. x86
    overrides that anyway and handles the TSC f*ckup in the
    CONFIG_HAVE_UNSTABLE_SCHED_CLOCK section of sched_clock.c which is
    completely irrelevant to any architecture which has a sane set of
    timers.

    The only extra magic which is required to avoid that (sub)arch
    maintainers need to specify a sched_clock() implementation to override
    the weak generic one is really the simple

    if (clock && (clock->flags & CLOCKSOURCE_USE_FOR_SCHED_CLOCK))
    return ....

    We need no locking there at all.

    We have a workaround in place, which overrides the weak sched_clock()
    implementation, to make x86 efficient, so why do we want to impose all
    that x86 crap on folks which deal with architectures which got the
    timers right ?

    Thanks,

    tglx


    \
     
     \ /
      Last update: 2009-05-27 02:25    [W:4.561 / U:0.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site