lkml.org 
[lkml]   [2007]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH (update 3)] timer: Run calc_load halfway through each round_jiffies second
(I've removed the other CC:s for now to avoid annoying them - assuming 
removing them from the CC: list doesn't do that).

On 02/03/07 22:32, Eric Dumazet wrote:
> Simon Arlott a écrit :
>> 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.
>
> You apparently have no idea of the mathematic formulae used.

You're right, I've not looked at exactly how it's done. I do know that
calling it early/late (by +/- 750ms/250ms) *once* on boot and every 7
weeks is going to have a tiny effect that will go away quickly.

> This formulae has a meaning *only* if EXP_1, EXP_5, EXP_15 are directly
> computed from the exact LOAD_FREQ value. If you change it 'randomly'
> without changing the EXP_... you basically compute a wrong value...

My comment asking about why you say it's complex is about the patch, not
the computation. After an initial sync the patch does not change how
often the calc_load computation is run or how it works, it will still be
run exactly the same way and every 5*HZ ticks as before (try adding a
printk to report when the count value's been changed by the call to
round_jiffies).

> So what ? Do you want to impress your boss with a given value ?

?

> Please dont mess it. Just ignore the avenrun values and let it die.
> You can change it to suit your needs, but it wont suit every needs.

I'm not sure you realise the problem the patch fixes, which is that since
2.6.20 tasks can use round_jiffies to run "in around X seconds time" at a
time when jiffies % HZ == 0 to avoid waking the CPU several times because
of multiple timers firing at random. This affects the calc_load process
really badly because it also tends to run at this time too. Moving calc_load
to always run halfway between a second will solve the problem.

> Imagine for example your task is awaken for 1us periods every HZ.
> Basically your cpu load should be HZ/1000000 (machine mostly idle)
> But computed 'load' will be 1.0
> This whole avenrun[] thing is plain stupid anyway. The load should be
> something between 0 and 1 (per cpu), to get a precise idea of cpu_power
> used/unused. Nobody mentioned avenrun[] values on lkml in the last decade.

If you're sure no one here cares about the values then I'll submit a patch
to remove them from /proc/loadavg (and wait it to get rejected). Until the
whole concept of load average and how it should be better calculated and
reported is solved the best that can be done is to not make things worse
like round_jiffies has done.

*I* know the values are nowhere near perfect, but I made a change to a
driver so that it uses round_jiffies to schedule status checking because
it's appropriate and it makes the load average values sit at 1.00 even when
idle - someone is going to complain about it and possibly take the time to
find out why. If they bisect it, my patch will show up as the cause of the
problem. (Assuming someone else uses this device; I sent an email to the
accessrunner list once -rc2-mm1 was released asking for people to test it).

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

\
 
 \ /
  Last update: 2007-03-03 00:57    [W:0.038 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site