lkml.org 
[lkml]   [2005]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/3] dynticks - implement no idle hz for x86
    On 05.09.2005 [22:55:01 +0530], Srivatsa Vaddagiri wrote:
    > On Mon, Sep 05, 2005 at 09:57:30AM -0700, Nishanth Aravamudan wrote:
    > > I think it's ok where it is. Currently, with x86, at least, you can have
    > > an independent interrupt source and time source (not true for all archs,
    > > of course, ppc64 being a good example, I think?) Perhaps "handler"
    >
    > By "independent" do you mean driven by separate clocks? PPC64 does
    > use decrementer as its interrupt source and Time-base-register as
    > its timesource AFAIK. Both are driven by the same clock I think.

    Well, independent as in not the same, I meant. Let me think about it and
    look at the code a bit, before making myself or anyone else more
    confused. John, do you have any input on what I'm getting at? I know we
    have discussed this before...

    > > What may be useful is something similar to what John Stultz does in his
    > > rework, attaching priorities to the various interrupt sources. For
    > > example, on x86, if we have an HPET, then we should use it, if not, then
    > > use APIC and PIT, but if the APIC doesn't exist in h/w, or is buggy
    > > (perhaps determined via a calibration loop), then only use the PIT.
    >
    > This logic is what the arch-code should follow in picking its interrupt
    > source and is independent of dyn-tick. dyn-tick just works with whatever
    > arch-code has chosen as its interrupt source.

    Yes, true. I didn't mean for the h/w interrupt source selection to be
    part of the arch-independent code, but that we might need to include a
    priority field in the interrupt_source structure to allow the
    arch-dependent code to do so.

    > > I agree. I guess max_skip, to me, is what the kernel thinks the
    > > interrupt source should maximally skip by, not what the interrupt source
    > > thinks it can do. So, I think it fits in fine with what you are saying
    > > and with the code you have in the current patch.
    >
    > Great!
    >
    > > I was just wondering; I guess it makes sense, but did you check to see
    > > if it ever *doesn't* get called? Like I said, __run_timers() [from how I
    >
    > Haven't tested that, but I feel can happen in practice, since we dont
    > control device interrupts.

    Well, it would be interesting to see if there's any difference without
    that function, or if it's even getting called.

    > > base->timer_jiffies) [the condition in run_timer_softirq()] is not. How
    > > much does it cost to raise the softirq, if it is going to return
    > > immediately from the callback?
    >
    > Don't know. It just felt nice to avoid any unnecessary invocations.

    Yes, but it also might add a function which doesn't need to be. I'll
    take a closer look at this too.

    Thanks,
    Nish
    -
    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-09-05 20:13    [W:4.079 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site