Re: [PATCH (updated)] timer: Run calc_load halfway through each round_jiffies second

[Simon Arlott <simon@fire.lp0.eu>]

On 01/01/02 03:05, Pavel Machek wrote:
>> Whenever jiffies is started at a multiple of 5*HZ or 
>> wraps, calc_load is run exactly on the second which is 
>> when tasks using round_jiffies will be scheduled to run. 
>> This has a bad effect on the load average, making it 
>> tend towards 1.00 if a task happens to run every time 
>> the load is being calculated.
>>
>> This changes calc_load so that it updates load half a 
>> second after any tasks scheduled using round_jiffies.
> 
> Hmm, otoh this makes calc_load more expensive, power-wise, because it
> needs to wake the cpu once more?

This was something I was concerned about, it's hard to avoid since it 
shouldn't be run when scheduled tasks are which leaves running it 
before those tasks run as the only other option. To do that you need 
some idea of how long it's going to take to run.

Mar  1 22:36:17 redrum [  639.147319] calc_load(1) jiffies=311500 count=0 [start]
Mar  1 22:36:17 redrum [  639.147331] calc_load... count=5000 [run]
Mar  1 22:36:17 redrum [  639.147336] calc_load... count=5000 [finish]

While I really doubt the accuracy of these timings using printk (they 
vary a lot only going as low as 4 + 4µs), it does show that 1ms is plenty 
of time and that it *could* be scheduled at 1 tick before the second even 
at HZ=1000.

Of course then you miss out on ever catching tasks scheduled with 
round_jiffies since they'd need to run for a full second to affect it.

Also, calc_load with NO_HZ only appears to run every time the system 
needed to wake up for something else (calc_load itself is already able 
to handle this appropriately), so this isn't as much of a problem as it 
might seem. Someone whose CPU only needs to be woken up every 5s (or 4.5s 
for a round_jiffies task) will find their load being higher than it 
should be - but the current version does that already. (Mine doesn't 
stay below 0.5 with NO_HZ because of this).

> Timetraveling, sorry.

Since Eric Dumazet seems to have disappeared for now I really need 
other people to comment on this too. Although you shouldn't literally 
time travel ;) (Date: Tue, 1 Jan 2002 03:05:07 +0000).

-- 
Simon Arlott