"Jeff V. Merkey" wrote:
>
>
> Not if you had a WorkToDo semantic, it would speed them up, but it would
> do so at the expense of other processes, so you are correct, it would be
> a tradeoff. The way NetWare is currently implemented, WorkToDo threads
> will always get run ahead of any other process in the NetWare kernel (I
> know -- I wrote it). What I have seen from this implementatin is
> lightning fast I/O responsiveness, but you are correct that I/O
> processing would be given priority over anything else that's running.
> You should give this one some thought before rejecting it so quickly.
> There may be a need for a "Linux I/O pump" config option for those
> customers who are using Linux as a I/O server (i.e. just for routing and
> remote file serving). I would love to see such an implementation and
> send it to a performance lab vs. NetWare and watch Linux kick NetWare's
> ass using NetWare's own performance tricks.
What I forgot to mention is that with a WorkToDo semantic, the AIO
callback could sill run on an interrupt context, I would just be able to
schedule SMP WOrkToDo's that would complete off a kernel process.
That's that part I failed to explain. Such a change would have little
impact on everything else (except that I/O would get priority
scheduling).
:-)
Jeff
>
> >
> > What you can do (obviously) in your callback, is to simply do something
> > like
> > - wake up the special thread you have for these kinds of blocks
> > - add the buffer head to the list of "completed" buffer heads (or
> > whatever)
> > - return, and wait for your thread to actually change the state of the
> > physical page in question (ie instead of marking the page up-to-date
> > and unlocking it, the thread would end up doing that).
> >
> > The "thread" may, of course, be a collection of threads, there's nothing
> > to say that you couldn't scale them to the number of CPU's or something
> > like that.
> >
> > You could obviously also select to do it with a very generic "completion
> > thread" that would do whatever the buffer head pointer implied that it
> > should do. But because 99% of all filesystems don't actually need anything
> > like this, I'd hate for this to be the default - it would just slow down
> > the regular filesystems that much rather just get the thing over and done
> > with directly from the interrupt.
>
> I am already doing pretty much what you describe. I'll keep doing it,
> and hope you change your mind in the future about the WorkToDo I/O
> optimization. It took a while, but you finally changed your mind on the
> spin_unlock() optimization, so there's always hope ....
>
> :-)
>
> Jeff
>
> >
> > Linus
-
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 : Mon May 15 2000 - 21:00:19 EST