On Mon, Sep 04, 2006 at 10:07:01AM +0200, Manuel Bouyer wrote: > What seems to happens is > that eventually all available buffers ends up in this queue between > strategy and vnd, and the thread doesn't have available buffers to > process the queue (and I suspect, to process a buffer from this queue, > more buffers a needed later, to process write to the vnode, eventually > raidframe or ccd, etc ...). Ah. I wondered what you had seen that caused you to rethink this. cgd is able to solve this problem for itself with its single reserved buffer, but it won't help if its stacked further with something else that can't make progress. IIRC raidframe has similar mechanisms (reserved pools), and perhaps vnd and any other drivers that need to expand buffer usage to make progress should also. If this can be factored out into common code (dksubr.c) all the better. I think most disk drivers don't, and traditionally didn't, need to do more than process the buffers they were handed, which is where this weakness comes from. There may also be an opportunity to look at how vnd releases the buffers it does get, perhaps it should be more aggressive about holding on to them and reusing them. Because it's running as a thread, if it lets them go there's every chance they'll have been consumed by the demand side by the time it wakes up again. > What we need is a way to limit the size of this queue. And I think all > strategy routine suffers from this, but in the general case it just causes > a performance problem and not a deadlock. Maybe a strategy should be > able to return EAGAIN, and have the caller deal with it. Another way would be to have the attempts to get buffers in the upper level code return EAGAIN, before they even get to the queue.. This is related to the backpressure and performance work. > > -- > Manuel Bouyer, LIP6, Universite Paris VI. > Manuel.Bouyer%lip6.fr@localhost > NetBSD: 26 ans d'experience feront toujours la difference > --
Attachment:
pgp982TZrbkmX.pgp
Description: PGP signature