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.
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 ...
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.- 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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:25 EST