Date: Mon, 8 Nov 2004 15:50:51 -0800
From: Andrew Morton <akpm@osdl.org>
To: Patrick Mau <mau@oscar.ping.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Workaround for wrapping loadaverage
Message-Id: <20041108155051.53c11fff.akpm@osdl.org>
In-Reply-To: <20041108102553.GA31980@oscar.prima.de>
References: <20041108001932.GA16641@oscar.prima.de>
	<20041108012707.1e141772.akpm@osdl.org>
	<20041108102553.GA31980@oscar.prima.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1471
Lines: 42


(PLease don't remove people from Cc:.  Just do reply-to-all).

Patrick Mau <mau@oscar.ping.de> wrote:
>
> On Mon, Nov 08, 2004 at 01:27:07AM -0800, Andrew Morton wrote:
> > Patrick Mau <mau@oscar.ping.de> wrote:
> > >
> > >  We can only account for 1024 runnable processes, since we have 22 bits
> > >  precision, I would like to suggest a patch to calc_load in kernel/timer.c
> > 
> > It's better than wrapping to zero...
> > 
> > Why do we need 11 bits after the binary point?
> 
> I tried various other combinations, the most interesting alternative was
> 8 bits precision. The exponential values would be:
> 
> 1 / e (5/60) * 256
> 235.53
> 
> 1 / e (5/300) * 256
> 251.76
> 
> 1 / e (5/900) * 256
> 254.58
> 
> If you would use 236, 252 and 255 the last to load calculations would
> get optimized into register shifts during calculation. The precision
> would be bad, but I personally don't mind loosing the fraction.

What would be the impact on the precision if we were to use 8 bits of
fraction?

An upper limit of 1024 tasks sounds a bit squeezy.  Even 8192 is a bit
uncomfortable.  Maybe we should just reimplement the whole thing, perhaps
in terms of tuples of 32-bit values: 32 bits each side of the binary point?
-
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/