linux-mips
[Top] [All Lists]

Re: [pathch] kernel/sched.c bogon?

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [pathch] kernel/sched.c bogon?
From: Jun Sun <jsun@mvista.com>
Date: Mon, 10 Mar 2003 09:59:07 -0800
Cc: Kip Walker <kwalker@broadcom.com>, linux-mips@linux-mips.org, jsun@mvista.com
In-reply-to: <20030310135531.B2206@linux-mips.org>; from ralf@linux-mips.org on Mon, Mar 10, 2003 at 01:55:31PM +0100
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <3E67EF64.152CFC6C@broadcom.com> <20030306174001.K26071@mvista.com> <20030310135531.B2206@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.2.5i
On Mon, Mar 10, 2003 at 01:55:31PM +0100, Ralf Baechle wrote:
> On Thu, Mar 06, 2003 at 05:40:01PM -0800, Jun Sun wrote:
> 
> > I reported this bug last May.  Apparently it is still not
> > taken up-stream.   Ralf, why don't we fix it here and push
> > it up from you?
> > 
> > BTW, this bug actually has effect on real-time performance under
> > preemptible kernel.
> 
> < = 2.4.x preemptible kernel is OPP.
> 
> >  It can delay the execution of the highest
> > priority real-time process from execution up to 1 jiffy.
> 
> Quite a number of users get_cycles() in the kernel assume it to return a
> 64-bit number.  I guess we'll have to fake a 64-bit counter in software ...
>

Whether we fake 64-bit or not, oldest_idle is declared as cycles_t.  
So comparing it with (cycles_t)-1 should be always be correct.  And it
actually makes a correct C program. :-)

I don't see any possible reason for rejecting the change.  My previous
report is probably just lost in the noise.

Jun

<Prev in Thread] Current Thread [Next in Thread>