linux-kernel - Re: [PATCH (update 3)] timer: Run calc_load halfway through each round

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45E85FC3.801@simon.arlott.org.uk>
Date:	Fri, 02 Mar 2007 17:32:51 +0000
From:	Simon Arlott <simon@...e.lp0.eu>
To:	Eric Dumazet <dada1@...mosbay.com>
CC:	akpm@...ux-foundation.org, Bill Irwin <bill.irwin@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	arjan@...ux.intel.com
Subject: Re: [PATCH (update 3)] timer: Run calc_load halfway through each
 round_jiffies second

On 02/03/07 16:35, Eric Dumazet wrote:
> On Friday 02 March 2007 16:15, Simon Arlott 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.
> 
> I believe this patch is too complex/hazardous and may break exp decay 
> computation.

Only for a single calculation whenever it has to adjust, which should only 
happen every 49.7 days (on 32-bit archs). (Or 5 minutes after booting... 
I always wondered why that happened and now I see it's initialised so it 
always wraps early). Whilst it is in sync with jiffies it will not affect 
the process - count is just set to the current value every time. Even with 
NO_HZ because jiffies will be correct when calc_load is called.

> (Even if nobody care about avenrun[] those days :), do you ? )
> 
> 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).

On HZ=100 it would happen every ~8 minutes for up to 10 seconds and never 
be noticed.

Using 5*HZ+2 would move this to ~167 and ~17 minutes which would mitigate 
the effect further still without changing the exp values.

1884.25 -> 1883.62
2014.15 -> 2014.02
2036.65 -> 2036.61

Will anyone notice if the load is adjusted slightly less frequently?

If this is considered preferable to adjusting calc_load to avoid almost all 
round_jiffies scheduled tasks (some of which may take longer than ~15ms to 
run), then I have no problems with it - I just needed something to stop my 
driver changes doing odd things to the load average for other people. I'll 
continue to run with this version, is it possible to add a Kconfig option 
for it somewhere?

-- 
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/