[lkml]   [2006]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: clocksource
    On Mon, 2006-06-05 at 01:50 +0200, Roman Zippel wrote:
    > Hi,
    > On Sun, 4 Jun 2006, Andrew Morton wrote:
    > > time-use-clocksource-infrastructure-for-update_wall_time.patch
    > I still disagree with the update_wall_time() changes, they should be kept
    > the new separate from this.

    Is this directly related to the next item (if so, how?), or just
    preference? I'd really like to avoid having multiple code paths for the
    timekeeping core, so I'd like to see this unified. I'm willing to
    optimize out bits w/ constants and whatnot, but I worry it will be a
    nightmare to maintain if we have multiple generic update_wall_time

    > The error algorithm is a somewhat old version
    > and can cause oscillation and thus a confused clock.

    Would you mind elaborating on this? Which aspect of the error algorithm
    is off? How does the clock become confused? Could you point to the line
    numbers, etc? I assume your last patchset contains the current version?

    > > time-let-user-request-precision-from-current_tick_length.patch
    > This is broken, as it simply throws away resolution depending on the
    > clock.

    So if the clock shift value is less then 12 (SHIFT_SCALE - 10), this is
    true, and currently that's only the jiffies case.

    Just to be clear, are you then suggesting that the accumulation in
    update_wall_time should be done in a fixed shifted nanosecond unit
    regardless of the clock shift value? Is SHIFT_SCALE-10, good enough in
    your mind for this?

    That seems not too difficult to do, and can be done w/ an incremental
    patch. I'll try to crank that out today.

    > These are two key problems, the rest can be fixed incrementally.

    If these are really blockers, I want to get them resolved in the next
    day or so (I'd really like to avoid having Andrew carry them for yet
    another cycle). So I'd appreciate your help in correcting these issues.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-05 22:22    [W:3.291 / U:13.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site