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
> to do with this fact :-) as I said, I know next to nothing here, just
> learning)
You are pretty close. The request free list is split in two, with
half the requests for reads and the other half for writes. But seeing
as reads are more important for the feel of the system, reads are
allowed to steal requests from the write free lists (instead of blocking
waiting for a free slot, when the read free list is empty). So reads
can basically eat the whole free list.
That's why we can get away with only only batching the, in essence,
last half of the total free list. Imagine reads eating the whole
free list -- in that case batching the write list is enough because
the write free list will be empty as well. Same thing goes for writes,
of course, the only difference is that they are restricted to their
own list.
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.
-- * Jens Axboe <axboe@suse.de> * SuSE Labs - 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