LKML Archive on
help / color / mirror / Atom feed
From: Simon Arlott <>
To: Eric Dumazet <>
Cc: Linux Kernel Mailing List <>
Subject: Re: [PATCH (update 3)] timer: Run calc_load halfway through each round_jiffies second
Date: Fri, 02 Mar 2007 23:54:13 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

(I've removed the other CC:s for now to avoid annoying them - assuming 
removing them from the CC: list doesn't do that).

On 02/03/07 22:32, Eric Dumazet wrote:
> Simon Arlott a écrit :
>> On 02/03/07 16:35, Eric Dumazet wrote:
>>> I believe this patch is too complex/hazardous and may break exp decay 
>>> computation.
>> I still don't know why you think it may change the computation of load 
>> (aside from at boot or jiffies wrapping), and it's not really complex 
>> at all. It is possible that someone will change the value of LOAD_FREQ 
>> to something other than a multiple of HZ and this won't work because 
>> it'll get rounded up to a whole second. That and the negligible extra 
>> processing time of doing round_jiffies every 5 seconds is the only 
>> problem I can see.
> You apparently have no idea of the mathematic formulae used.

You're right, I've not looked at exactly how it's done. I do know that 
calling it early/late (by +/- 750ms/250ms) *once* on boot and every 7 
weeks is going to have a tiny effect that will go away quickly.

> This formulae has a meaning *only* if EXP_1, EXP_5, EXP_15 are directly 
> computed from the exact LOAD_FREQ value. If you change it 'randomly' 
> without changing the EXP_... you basically compute a wrong value...

My comment asking about why you say it's complex is about the patch, not 
the computation. After an initial sync the patch does not change how 
often the calc_load computation is run or how it works, it will still be 
run exactly the same way and every 5*HZ ticks as before (try adding a 
printk to report when the count value's been changed by the call to 

> So what ? Do you want to impress your boss with a given value ?


> Please dont mess it. Just ignore the avenrun values and let it die.
> You can change it to suit your needs, but it wont suit every needs.

I'm not sure you realise the problem the patch fixes, which is that since 
2.6.20 tasks can use round_jiffies to run "in around X seconds time" at a 
time when jiffies % HZ == 0 to avoid waking the CPU several times because 
of multiple timers firing at random. This affects the calc_load process 
really badly because it also tends to run at this time too. Moving calc_load 
to always run halfway between a second will solve the problem.

> Imagine for example your task is awaken for 1us periods every HZ.
> Basically your cpu load should be HZ/1000000 (machine mostly idle)
> But computed 'load' will be 1.0
> This whole avenrun[] thing is plain stupid anyway. The load should be 
> something between 0 and 1 (per cpu), to get a precise idea of cpu_power 
> used/unused. Nobody mentioned avenrun[] values on lkml in the last decade.

If you're sure no one here cares about the values then I'll submit a patch 
to remove them from /proc/loadavg (and wait it to get rejected). Until the 
whole concept of load average and how it should be better calculated and 
reported is solved the best that can be done is to not make things worse 
like round_jiffies has done.

*I* know the values are nowhere near perfect, but I made a change to a 
driver so that it uses round_jiffies to schedule status checking because 
it's appropriate and it makes the load average values sit at 1.00 even when 
idle - someone is going to complain about it and possibly take the time to 
find out why. If they bisect it, my patch will show up as the cause of the 
problem. (Assuming someone else uses this device; I sent an email to the 
accessrunner list once -rc2-mm1 was released asking for people to test it).

Simon Arlott

      reply	other threads:[~2007-03-02 23:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-24 15:19 round_jiffies and load average Simon Arlott
2007-03-01  9:11 ` Simon Arlott
2007-03-01 18:52   ` [PATCH] timer: Add an initial 0.5s delay to calc_load Simon Arlott
2007-03-01 22:52     ` [PATCH (updated)] timer: Run calc_load halfway through each round_jiffies second Simon Arlott
2002-01-01  3:05       ` Pavel Machek
2007-03-05 22:35         ` Simon Arlott
2007-03-06 18:42           ` [PATCH (update 4)] " Simon Arlott
2007-03-06 22:20         ` [PATCH (updated)] " Chuck Ebbert
2007-03-01 23:10       ` Bill Irwin
2007-03-02 10:15         ` [PATCH (update 2)] " Simon Arlott
2007-03-02 15:15           ` [PATCH (update 3)] " Simon Arlott
2007-03-02 16:35             ` Eric Dumazet
2007-03-02 17:32               ` Simon Arlott
2007-03-02 18:03                 ` Eric Dumazet
2007-03-02 20:14                   ` Simon Arlott
2007-03-02 22:32                     ` Eric Dumazet
2007-03-02 23:54                       ` Simon Arlott [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [PATCH (update 3)] timer: Run calc_load halfway through each round_jiffies second' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).