lkml.org 
[lkml]   [2005]   [Sep]   [7]   [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 Wed, Sep 07, 2005 at 10:23:15AM -0700, Nishanth Aravamudan wrote:
    > > > #define DYN_TICK_MIN_SKIP 2
    >
    > Another point. Why is this 2? I guess if you're going to make it 2, why
    > bother defining/checking it at all?

    I think that should be arch-specific.


    > > > void (*disable_dyn_tick) (void);
    > > > unsigned long (*reprogram) (unsigned long); /* return number of ticks skipped */
    > >
    > > How will it be able to return the number of ticks skipped? Or are you
    > > referring to max_skip here?
    >
    > Yes, maybe this can be a void function... I was thinking more along the
    > lines of you can send whatever request you want to reprogram(), it does
    > what it can with the request (cuts it short if too long, ignores it if
    > too short) and then returns what it actually did.

    Looks fine in that case to have a non-void return.

    > > In x86-like architectures, there can be multiple ticksources that can
    > > be simultaneously active - ex: APIC and PIT. So one
    > > "current_ticksource" doesnt capture that fact?
    >
    > Not really, though, right? Only one is registered to do the timer
    > callbacks?

    True.

    > So, for x86, if you use the PIT ticksource, you only need to
    > be PIT aware, but if you use the APIC ticksource, then it needs to be
    > aware of the APIC and PIT (I believe you mentioned they are tied to each
    > other), but that's ticksource-specific. CMIIW, though, please.

    I was going more by what meaning 'current_ticksource' may give - from
    a pure "ticksource" perspective, both (PIT/APIC) are tick sources!
    Thats why current_ticksource may not be a good term.

    > Maybe you are right. I don't like having a separate struct for the
    > state, though, and the dyn_tick_timer struct doesn't have a
    > recover_time() style member. If you look closely, my structure is

    I agree we can remove the separate struct for state and have
    recover_time member. Although in x86, it may have to be a wrapper
    around mark_offset() since mark_offset does not recover time
    completely (it expect the callee to recover one remaining tick).

    > basically exactly what the x86 work has, just some different names
    > (don't need arch_ prefix, for instance, because it's clearly
    > dyn_tick_timer specific, etc.) I also would like to hear from the s390
    > folks about their issues/opinions.

    Martin Schwidefsky (whom I have CC'ed) may be the person who can comment on
    behalf of s390.

    > Yes, true. I'm wondering, do we need to make the
    > current_ticksource/current_dyn_tick_timer per-CPU? I am just wondering
    > how to gracefully handle the SMP case. Or is that not a problem?

    I don't see that current_ticksource/current_dyn_tick_timer to be write-heavy.
    In fact I see them to be initialied during bootup and after that mostly
    read-only. That may not warrant a per-CPU structure.


    --


    Thanks and Regards,
    Srivatsa Vaddagiri,
    Linux Technology Center,
    IBM Software Labs,
    Bangalore, INDIA - 560017
    -
    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-07 20:17    [W:0.025 / U:31.492 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site