lkml.org 
[lkml]   [2005]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] dynamic tick patch
    * Benjamin Herrenschmidt <benh@kernel.crashing.org> [050118 20:22]:
    > On Tue, 2005-01-18 at 16:05 -0800, Tony Lindgren wrote:
    > > Hi all,
    > >
    > > Attached is the dynamic tick patch for x86 to play with
    > > as I promised in few threads earlier on this list.[1][2]
    > >
    > > The dynamic tick patch does following:
    > >
    > > .../...
    >
    > Nice, that's exactly what I want on ppc to allow the laptops to have the
    > CPU "nap" longer when idle ! I'll look into adding ppc support to your
    > patch soon.

    Great!

    > BTW. Is it possible, when entering the "idle" loop, to quickly know an
    > estimate of when the next tick shoud actually kick in ?

    Yes, see next_timer_interrupt() for that. The interrupt loop should
    be pretty much the same on all archs. Then calling the timer
    interrupt from other interrupts removes any latency issues with the
    timer. But that's pretty much all the patch does.

    > Also, looking at the patch, I think it mixes a bit too much of x86
    > things with generic stuffs... like pm_idle an x86 thing.

    Yes, the idle module should probably be in drivers/acpi or something
    to allow loading other custom PM modules.

    > Other implementation details comments: Do you need all those globals to
    > be exported ? And give them better names than "ltt", that makes using of
    > system.map quite annoying ;)

    Oops, ltt, is probably left-over from low-tick-timer that I used
    first as a name... I'll fix that :)

    > I don't understand your comment about "we must have all processors idle"
    > as well...

    Hmmm, maybe it's not needed any longer? Have to try it out. I had
    some issues with SMP when I started doing the patch.

    > So while the whole thing is interesting, I dislike the actual
    > kernel/dyn-tick-timer.c implementation, which should be moved to arch
    > stuff at this point imho.

    Yeah, there's not much shared code yet, when I started I expected to
    share more code between ARM and x86. But the timer framework is
    quite arch specific. So far only registering and /sys control to
    enable seems common. Maybe some inline functions too, but a common
    header might be enough.

    Regards,

    Tony
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:3.145 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site