[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56A17B1B.9030104@veribox.net>
Date: Fri, 22 Jan 2016 01:43:07 +0100
From: Vik Heyndrickx <vik.heyndrickx@...ibox.net>
To: Doug Smythies <dsmythies@...us.net>,
'Peter Zijlstra' <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched: loadavg 0.00, 0.01, 0.05 on idle
On 21/01/2016 19:38, Doug Smythies wrote:
> new = (old * 2037 + load * (2048 - 2037)) / 2048
> new = (1862 * 2037 + 2048 * (2048 - 2037)) / 2048
> new = 1862
>
> So, the 100% load will always be shown as 91% (double the old limit).
Math seems sound, but the fact is that the load on all my test machines
now drops to 0.00/0.00/0.00 on idle, and increases to e.g. on my octa-
core 8.00/8.00/8.00 on full load.
I used mprime -t to cause a full load on all cores.
load can never drop below 0, but can and will exceed 2048 unless nothing
else is running, which is then likely the reason why 8.00 is actually
reached for the 5 and 15 minute value despite the math here above.
I would not worry too much about the accuracy, because, with or without
the rounding, it takes more than three quarters of an hour to reach 100%
15-minute loadavg from idle, or the other way around 0% from full load.
> I have been running this proposed code with 100% load on CPU 7 for a couple
> of hours now, and the 15 minute load average is stuck at 0.91.
In theory possible, but any instantaneous load above 100% will raise
that 0.91 further.
I think I can easily change the calc_load algorithm further to have the
best of both worlds, but it will still take 45 minutes to reach a
15-minute avgload.
After 40 minutes, and just to be sure, I checked again, and my buildhost
now has the following load: 8.00, 8.02, 7.94.
--
Vik
Powered by blists - more mailing lists