public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Simon Arlott <simon@fire.lp0.eu>
Cc: akpm@linux-foundation.org, Bill Irwin <bill.irwin@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	arjan@linux.intel.com
Subject: Re: [PATCH (update 3)] timer: Run calc_load halfway through each round_jiffies second
Date: Fri, 02 Mar 2007 23:32:10 +0100	[thread overview]
Message-ID: <45E8A5EA.3030207@cosmosbay.com> (raw)
In-Reply-To: <45E885A8.5060708@simon.arlott.org.uk>

Simon Arlott a écrit :
> On 02/03/07 18:03, Eric Dumazet wrote:
>> On Friday 02 March 2007 18:32, Simon Arlott wrote:
>>> On 02/03/07 16:35, Eric Dumazet wrote:
>>
>>>> You could just change LOAD_FREQ from (5*HZ) to (5*HZ+1)
>>>> You can see that 5.01 instead of 5.00 second gives the same EXP_xx
>>>> values.
>>>>
>>>> So (5*HZ + 1) is safe. (because HZ >= 100)
>>> On HZ=1000, this would cause the load average to be pushed towards +1.00
>>> for up to 2 minutes every ~83 minutes with no obvious cause. (If a task
>>> takes ~10-20ms to run, so 20 runs are needed at HZ=1000 before it passes
>>> it again).
>>
>> Nope, you dont quite understand how load (avenrun[]) is computed.
>> Not exactly 1.0 as you think !
>> Then in the next intervals (if active count is 0), it will decrease 
>> 'slowly' : 0.0735627
>> 0.0676809
>> 0.0622695
>> 0.0572907
>>
>> In average, your load factor close to reality.
> 
> I knew that; but the task runs for more than 1 tick and it takes until 
> the next calc_load run before it moves on even 1 tick.
> 
>> Just try my suggestion, it should work. I even proved it in my 
>> previous mail :)
> 
> With HZ=1000, the active count will be 1 up to 20 times in a row before 
> it becomes out of sync with when the task is run again. This is ample 
> time for the load value itself to get closer to 1:
> $ uptime; (yes>/dev/null &); sleep 100; uptime
> 20:00:29 up  4:35,  7 users,  load average: 0.33, 0.51, 0.78
> 20:02:09 up  4:37,  7 users,  load average: 0.97, 0.67, 0.81
> (not very useful results since the load isn't at 0.00 very often)
> 
> 
> 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.

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... 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.

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.


  reply	other threads:[~2007-03-02 22:33 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 [this message]
2007-03-02 23:54                       ` Simon Arlott

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=45E8A5EA.3030207@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=bill.irwin@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simon@fire.lp0.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox