lkml.org 
[lkml]   [2000]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] preemptive kernel, preemptive-2.3.52-A7
yodaiken@fsmlabs.com wrote:
>
> On Wed, Mar 29, 2000 at 06:36:41PM +0200, Ingo Molnar wrote:
> >
> > On Wed, 29 Mar 2000 yodaiken@fsmlabs.com wrote:
> >
> > > If read/write is too slow, figuring out some way to force it into mmap
> > > or do something else smart is an alternative to checking needs
> > > resched.
> >
> > read/write is almost never 'too slow'. The code path David was talking
> > about is the _cached_ read/write path, which can be broken up into tiny
> > need_resched sections just fine - and this is done in the lowlatency
> > patch. No mmap or else is needed. Maybe i'm missing your point?
>
> So perhaps I'm totally confused but here's what I think might happen.
> Scene1: without need_resched checks
> Process A does a 4Meg write: kernel wastes 20 milliseconds
> copying data into buffers, releases the buffers to the i/o
> system and returns. Cache is pretty much blown.
> In the meantime 10 interactive tasks have all become ready for
> action and are nicely sorted on the runq. When process A tries
> to go back into user mode, it switches to the highest priority of
> these and each one gets a full slice, runs and goes to the next one.

This is a disaster if you want to handle multimedia stuff.
In this scenario all (multimedia) drivers has to cache at least 20
milliseconds
of data. This includes CD-R/RW drivers. And this is not the upper
bound...

>
> Scene2: with need_resched
> Process A copies one block
> One higher priority interactive process becomes ready and
> we resched. This process rapidly returns to A
> which starts writing again , the second interactive process
> becomes ready and ...
>
> After each switch A wipes the cache, we have an additional
> switch, and total compute time is much longer not to mention
> that we double the number of context switches.
>
> Scene 2 is not a disaster, but ...

Note the conditions:
a) A big copy going on
b) one/several higher prio processes gets ready during the copy

And note the result:
You get a response from the interactive process before the copy is
finished!
Would you complain?

Look at it more like giving application developers some kind of limit
for their buffers.

A problem will be that the more developers know about it, the more will
they
use it, the more processes will compete at high prio, the more likely it
will
be to break the limits... There need to be design guidelines too!
Everyone can
not put their app at highest SCHED_FIFO priority...

/RogerL

--
Home page:
http://www.norran.net/nra02596/

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

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.146 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site