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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 02 Mar 2007 20:14:32 +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 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.

I accidentally left LOAD_FREQ at 5 instead of 5*HZ and had a printk in there, 
it still worked fine aside from the load average going up and down every tick.

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