lkml.org 
[lkml]   [2012]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Inconsistent load average on tickless kernels
    On Mon, Mar 5, 2012 at 11:57 AM, Lesław Kopeć
    <leslaw.kopec@nasza-klasa.pl> wrote:
    > On 29.02.2012 13:06, Peter Zijlstra wrote:
    >
    >> Missing here is a kernel build with CONFIG_NO_HZ but booted with
    >> nohz=off; this would be an interesting data point because it includes
    >> all the funny code but still ticks are the right frequency.
    >
    > You've asked for it and you got it. I have rebooted some servers with
    > nohz=off parameter set on kernels complied with CONFIG_NO_HZ=y. They're
    > the ones listed below with 'off' suffix.
    >
    > On 29.02.2012 17:24, Peter Zijlstra wrote:
    >
    >> Hrmm, this suggests we age too hard with nohz code.. in your test case
    >> is there significant idle time? That is, suppose you run each cpu at 30%
    >> what is the period of you load? Running 3s out of 10s is significantly
    >> different from running .3ms out of 1ms.
    >
    > It's definitely more similar to the second case - very frequent, but
    > short bursts of activity. A single process does a tiny bit of
    > computation mixed with a fair amount of network activity on each
    > request. There are 80 such processes which are responsible for majority
    > of system load.
    >
    > On 29.02.2012 18:03, Peter Zijlstra wrote:
    >
    >>> The only thing I could find is that on nohz we can confuse the per-rq
    >>> sample period, does the below make a difference?
    >>
    >> Uhm, something like so that is..
    >>
    >> ---
    >>  kernel/sched/core.c |    3 ++-
    >>  1 files changed, 2 insertions(+), 1 deletions(-)
    >>
    >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
    >> index d7c4322..44f61df 100644
    >> --- a/kernel/sched/core.c
    >> +++ b/kernel/sched/core.c
    >> @@ -2380,7 +2380,8 @@ static void calc_load_account_active(struct rq *this_rq)
    >>       if (delta)
    >>               atomic_long_add(delta, &calc_load_tasks);
    >>
    >> -     this_rq->calc_load_update += LOAD_FREQ;
    >> +     while (!time_before(jiffies, this_rq->calc_load_update))
    >> +             this_rq->calc_load_update += LOAD_FREQ;
    >>  }
    >>
    >>  /*
    >>
    >
    > I have compiled another batch of kernels with this patch applied
    > (they're the ones with 'patch0' suffix). The only difference was the
    > patch had to go to kernel/sched.c, but that's what you get when not
    > using the latest sources. Anyway, here are the results accompanied by a
    > pretty picture [1]:
    >
    >                                        std     off     patch0
    > 2.6.32.55-no-hz                         0.76    0.91    -
    > 2.6.32.55-no-hz-74f5187ac8              6.41    9.40    4.93
    > 2.6.32.55-no-hz-0f004f5a69              0.78    0.92    0.90
    > 2.6.37-rc5-no-hz-0f004f5a69             0.95    0.92    0.86
    > 2.6.37-rc5-no-hz-pre-0f004f5a69         9.16    10.47   8.02
    >
    > It seems that the patch didn't help much on kernels with 0f004f5a69
    > applied. The ones with just 74f5187ac8 are reporting a more plausible
    > values, but slightly lower than the ones without patch0. Am I right to
    > assume that the correct load values are the ones produced by kernels
    > complied with CONFIG_NO_HZ=n? Should they be the baseline?
    >
    > I can run additional tests if you have other leads to follow. Is there a
    > particular kernel version I should focus on? If not I will continue
    > to use the current bundle. I'm also planning to give the latest stable
    > release a spin.

    I can confirm these results on 3.2.8. Booting with nohz=off makes no
    difference. Applying the patch to kernel/sched.c made no noticeable
    difference either.

    Aman

    >
    >
    > [1] http://img835.imageshack.us/img835/2204/kernelload.png
    >
    > --
    > Lesław Kopeć
    >
    --
    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: 2012-03-05 23:49    [W:0.028 / U:0.480 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site