[lkml]   [2006]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] simplify update_times (avoid jiffies/jiffies_64 aliasing problem)
    On Thu, 2006-03-02 at 19:04 -0800, Andrew Morton wrote:
    > I'm actually creaking under the load of timer patches over here. A lot of
    > the above code has been heavily redone in John's time patches. I guess the
    > above optimisation is still relevant after John's work (?) but we need to
    > decide what to do. Now is as good a time as any.
    > John, that timer stuff is so fundamental and hits on code which has
    > historically been so fragile that I'm not sure it's even 2.6.17 material.
    > In which case we should sneak patches like the above underneath it all.
    > Or we decide to take your work into 2.6.17, in which case the above needs
    > to be redone for that context.

    I'm not opposed to queuing it up as it seems like a logical cleanup. I'd
    be fine with it going in before my patch, however it still needs to
    address i386 lost tick compensation. I worry that addressing that issue
    before my patchset (which makes the lost tick compensation unnecessary)
    might be a bit more complex. I think it would be easier going in after
    my patch. I do think the barrier fix (with a comment) is a good short
    term fix.

    Atsushi: Your thoughts?

    > I'm not sure how to resolve this, really. Worried. Have you socialised
    > those changes with architecture maintainers? If so, what was the feedback?

    As to the larger issue of if my patch set is 2.6.17 ready, I'd like to
    think it is. There are some optimizations I'm working on that Roman has
    suggested that should improve some of the periodic_hook overhead and the
    NTP accuracy, but so far I've not noticed the changes helping or hurting
    much (also I haven't gotten any feedback on my last attempt). I plan on
    continuing that work, but I feel the benefits (as in the number of real
    problems that it would resolve) for pushing the patchset that is in -mm
    without the finer performance tuning is large enough for it to be

    But again, you're concerns are valid, there appears to be a lack of
    enthusiasm in the community both for and against the changes. And I
    understand, as I've got lots of other things I need to do as well, and
    reviewing a large change like this can take some time that I'm sure
    folks are short on.

    Maybe I should work on selling it more, I just have been at it for so
    long with this patch set that I feel I'm boring folks with the constant
    and repetitive "provides robust behavior in the face of lost ticks and
    enables other development like high-res timers and realtime" schtick.

    But I guess I'll try to ping some folks individually see if I can't stir
    up some discussion and get some additional feedback on the issue.


    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-03-03 21:19    [W:0.023 / U:7.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site