Jens Axboe wrote:
>
> On Thu, Aug 24 2000, David Mansfield wrote:
> > > Okay, here's a new version. The pending list always contains requests
> > > from the write list, so we can use list_splice. We batch a quarter
> > > the size freelist, i.e. half the size of the write list -- whether
> > > that is a good number, I don't know. I suspect it should be less
> > > than that.
> >
> > To preface this, I don't really know what I'm talking about so ignore me
> > if this is stupid.
>
> There are no stupid questions ;-)
>
> > I understand you are coalescing the freed requests to add them back to
> > the freelist in a batch, but this is done only for 'write' requests, so
> > it makes sense that the wake_up is postponed until the list_splice of
> > the pending_list into the write_list.
> >
> > But, it looks like with your patch, if the req->free_list is the 'read'
> > freelist the wake_up will *never* happen (unlike in the original
> > version). Is this missing wake_up intended?
> >
> > (you mentioned in an earlier post that read requests can be stolen from
> > the write free_list, I suppose if your code is correct it has something
> So as long as there are free slots in the read list, no processes
> will be blocked waiting for an entry, so there's no one to wake up.
>
Technically speaking, however, the completion of a request that was
taken from the read list doesn't guarantee that there are still free
slots in the read list, but rather that there *were* free slots in the
read list at the time the request was made.
If between that time and now a slew of requests were made, enough to use
all available requests, plus one more read for the sake of argument,
which will be put onto the wait queue. Now this new free request is put
onto the read free_list, but the queue is not activated. Then another
read request comes in, it will use the free request while the one on the
wait queue starves.
In fact, the requests that are going to go back onto the read free_list
when they are complete, at this point, will be the oldest ones, since
'back then' there was still room in the read free_list. Since they are
oldest, they are also probably going to be the first to be completed.
So that means that you have potentially (pathological but possible) the
entire read_list free, with a reader waiting on the queue for a free
request. Of course new readers will continue happily, but the waiting
one will be starved until your quota of batched write request freeing
completes and the queue is activated.
David Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:14 EST