Messages in this thread |  | | Date | Fri, 25 Aug 2000 00:50:52 +0200 | From | Jens Axboe <> | Subject | Re: ll_rw_blk.c fails to merge requests. Help! |
| |
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/
|  |