Linus Torvalds wrote:
>
> On Thu, 11 May 2000, Jeff V. Merkey wrote:
> >
> > One more item that did not get addressed. Can we change the callback to
> > acquire a sleeping context rather than run on an interrupt?
>
> Nope. That would slow down things incredibly.
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 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