[lkml]   [2009]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] sched: Support current clocksource handling in fallback sched_clock().

    On Tue, 26 May 2009, john stultz wrote:
    > > 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.
    > Yes, if we're dropping a clocksource we should also drop the bit. That
    > shouldn't be a problem.
    > The point I was making, is that multiple clocksources may be registered
    > at one time (TSC, ACPI_PM, etc). But only one is being managed by the
    > timekeeping code (clock). So there may be the case where the
    > sched_clock() is different then the timekeeping clock (which is common
    > on x86).
    > So I suspect we need a special hook that grabs the best _SCHED_CLOCK
    > clocksource (as computed at clocksource registration time) and provides
    > it to the generic sched_clock() interface.

    this is not about x86 and its inferiour timer hardware
    implementation. We talk about sane architectures which do not have
    that problems at all. x86 takes a different code path and overrides
    the generic weak sched_clock implememtation anyway. So what ?



     \ /
      Last update: 2009-05-27 02:31    [W:0.021 / U:53.344 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site