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: <45EC9B15.6090908@simon.arlott.org.uk>
Date:	Mon, 05 Mar 2007 22:35:01 +0000
From:	Simon Arlott <simon@...e.lp0.eu>
To:	Pavel Machek <pavel@....cz>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	akpm@...ux-foundation.org, arjan@...ux.intel.com
Subject: Re: [PATCH (updated)] timer: Run calc_load halfway through each round_jiffies
 second

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ