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 Sun, Sep 04, 2005 at 10:48:13PM -0700, Nishanth Aravamudan wrote:
    > Admittedly, I don't think SMP ARM has been around all that long? Maybe
    > the existing code just has not been extended.

    Yeah, maybe ARM never cared for SMP. But we do care :)

    > I'm not sure on this. It's going to be NULL for other architectures, or
    > end up being called by the reprogram() call for the last CPU to go idle,
    > right (presuming there isn't a separate TOD source, like in x86). I
    > think it is better to be in the reprogram() interface.

    Non-x86 could have it set to NULL, in which case it doesn't get called.
    (I know the current code does not take care of this situation).
    But having an explicit 'all_cpus_idle' interface may be good, since
    Tony talked of idling some devices when all CPUs are idle. So it
    probably has non-x86/PIT uses too.

    > > 6. S390 makes use of notifier mechanism to notify when CPUs are coming
    > > in and out of idle state. Don't know how it will be used in other
    > > arches. But obviously, if we are talking of unifying, we have to
    > > provide one.
    >
    > Couldn't that be part of the s390-specific init() code? That member is
    > non-existent in the ARM implementation either, but it should not be hard
    > to add? The only issue I see, though, is that the function which the
    > init() member points to should not be marked __init, as we could have an
    > empty pointer later on?

    If we consider that only s390 needs it and other arch's dont, then it need
    not be even part of the init code. Basically the notifier list can be maintained
    by s390 in its arch-code entirely and have 'stop_hz_timer' call into
    dyn_tick_reprogram_timer (or something like that)? But I feel there will be
    other uses for the notifier list (I know the slab reap timer fires every two
    seconds and that may be unnecessary on idle CPUs if it is not reaping
    anything - perhaps it could use such a notifier to fire at longer intervals on
    idle CPUs? That may be true of other short-timers that kernel/drivers may be
    using. This is just a thought and may need more consideration before we
    put a notifier mechanism in arch-independent code).

    > I'm not sure on this last one, though, what part of the state can't
    > simply be represented by an integer with appropriate &-ing?

    Everything can be represented in bits! I was just comparing composition
    of structures in ARM and x86. The state bitfield is part of
    'struct dyn_tick_timer' itself in ARM while it is part of a separate structure
    (dyn_tick_state) in x86. Similar minor points need to be sorted out while
    unifying.


    --


    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-05 08:35    [W:8.301 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site