[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <462DBEF6.70205@dawes.za.net>
Date: Tue, 24 Apr 2007 10:25:26 +0200
From: Rogan Dawes <lists@...es.za.net>
To: Ingo Molnar <mingo@...e.hu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Nick Piggin <npiggin@...e.de>,
Gene Heskett <gene.heskett@...il.com>,
Juliusz Chroboczek <jch@....jussieu.fr>,
Mike Galbraith <efault@....de>, linux-kernel@...r.kernel.org,
Peter Williams <pwil3058@...pond.net.au>,
ck list <ck@....kolivas.org>,
Thomas Gleixner <tglx@...utronix.de>,
William Lee Irwin III <wli@...omorphy.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Bill Davidsen <davidsen@....com>, Willy Tarreau <w@....eu>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [REPORT] cfs-v4 vs sd-0.44
Ingo Molnar wrote:
> * Rogan Dawes <lists@...es.za.net> wrote:
>
>>> if (p_to && p->wait_runtime > 0) {
>>> p->wait_runtime >>= 1;
>>> p_to->wait_runtime += p->wait_runtime;
>>> }
>>>
>>> the above is the basic expression of: "charge a positive bank balance".
>>>
>> [..]
>>
>>> [note, due to the nanoseconds unit there's no rounding loss to worry
>>> about.]
>> Surely if you divide 5 nanoseconds by 2, you'll get a rounding loss?
>
> yes. But not that we'll only truly have to worry about that when we'll
> have context-switching performance in that range - currently it's at
> least 2-3 orders of magnitude above that. Microseconds seemed to me to
> be too coarse already, that's why i picked nanoseconds and 64-bit
> arithmetics for CFS.
>
> Ingo
I guess my point was if we somehow get to an odd number of nanoseconds,
we'd end up with rounding errors. I'm not sure if your algorithm will
ever allow that.
Rogan
-
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