lkml.org 
[lkml]   [2009]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC tip/core/rcu 1/3] rcu: The Bloatwatch Edition, v7
    Steven Rostedt wrote:
    > But isn't the tick_nohz_stop_sched_tick have several exits?
    >
    > void tick_nohz_stop_sched_tick(int inidle)
    > {
    > [..]
    >
    > if (!inidle && !ts->inidle)
    > goto end;
    >
    > ts->inidle = 1;
    >
    > [..]
    >
    > if (!ts->tick_stopped) {
    > [..]
    > ts->tick_stopped = 1;
    > ts->idle_jiffies = last_jiffies;
    > rcu_enter_nohz();
    > }
    > [..]
    >
    >
    > So I'm not sure calling tick_nohz_stop_sched_tick twice equals calling
    > rcu_enter_nohz twice.
    >

    Hi, tglx, steven,

    (Thank to tglx for helping me at the Japan Linux Symposium)

    I found something weird about NO_HZ, maybe I misunderstood the codes.

    see this flow:

    cpu idle
    enter nohz
    cpu halt
    ---->interrupt happens
    irq_enter()
    we don't reprogram the clock device #1
    irq_exit()
    tick_nohz_stop_sched_tick(inidle = 0)
    something disallow this cpu reenter nohz #2
    we don't reprogram the clock device #3
    <----interrupt return
    cpu halt again and wait interrupt for a long time than expected #4
    exit nohz


    #1 tick_nohz_kick_tick() is disabled in the current mainline kernel,
    so we don't calls tick_nohz_restart(ts, now) when irq_enter()

    static void tick_nohz_kick_tick(int cpu)
    {
    #if 0 <------------- here
    /* Switch back to 2.6.27 behaviour */

    struct tick_sched *ts = &per_cpu(tick_cpu_sched, cpu);
    ktime_t delta, now;

    if (!ts->tick_stopped)
    return;

    /*
    * Do not touch the tick device, when the next expiry is either
    * already reached or less/equal than the tick period.
    */
    now = ktime_get();
    delta = ktime_sub(hrtimer_get_expires(&ts->sched_timer), now);
    if (delta.tv64 <= tick_period.tv64)
    return;

    tick_nohz_restart(ts, now); <----------- here
    #endif
    }


    #2 When rcu_needs_cpu() or printk_needs_cpu()
    returns true then tick_nohz_stop_sched_tick() will just return.

    #3 And we don't reprogram the clock device when #2 happens

    #4 So we may be in nohz for a long time than expected, but actually
    we have some work to do. (rcu, printk... etc)

    So I think, we need to reprogram the clock device and restart the tick
    when #2 happens, or there is something that I have misunderstood.

    Thanks, Lai



    > -- Steve
    >
    >>> So I do believe that rcu_enter_nohz() and rcu_exit_nohz() are in fact
    >>> invoked in pairs. One strange thing about this is that the idle loop
    >>> first invokes rcu_enter_nohz(), then invokes rcu_exit_nohz(), while
    >>> an interrupt handler first invokes rcu_irq_enter() and then invokes
    >>> rcu_irq_exit(). So the idle loop enters dyntick-idle mode and then
    >>> leaves it, while an interrupt handler might leave dyntick-idle mode and
    >>> then re-enter it.
    >>>
    >>> Or am I still missing something here?
    >>>
    >>> Thanx, Paul
    >>>
    >>>
    >
    >
    >




    \
     
     \ /
      Last update: 2009-10-27 08:29    [W:0.027 / U:0.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site