Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Mike Galbraith <efault@gmx.de>]

At 01:57 AM 4/5/2005 -0600, Zwane Mwaikambo wrote:
> On Tue, 5 Apr 2005, Esben Nielsen wrote:
>
> > > I'm sure a lot of the yield() users could be converted to
> > > schedule_timeout(), some of the users i saw were for low memory 
> conditions
> > > where we want other tasks to make progress and complete so that we a bit
> > > more free memory.
> > >
> >
> > Easy, but damn ugly. Completions are the right answer. The memory system
> > needs a queue system where tasks can sleep (with a timeout) until the
> > right amount of memory is available instead of half busy-looping.
>
> I agree entirely, that would definitely be a better way to go eventually.

I wouldn't bet on it.  There used to be a queue - minus the 
timeout.  Throughput improved markedly with it's removal.

That said, yield()s in the kernel can be quite evil.  I once instrumented 
semaphores, and under hefty load, frequently found tasks waiting for a 
semaphore held by someone in the expired array.  When you've got a busy 
cpu, that wait can be _extremely_ painful.  The yield()s in mm/*.c are long 
gone (thank god), but after a quick grep/peek, I can imagine the one in 
free_more_memory() causing some throughput grief in a cpu intense 
environment, and the one in __wait_on_freeing_inode() would punt you into 
the dungeon while you're holding the inode lock... that looks like it could 
be pretty unpleasant.

        -Mike 

-
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/