Hello, On 08/19/2010 12:32 PM, Kiyoshi Ueda wrote: >> I see but single pending flush and steady write streams w/o saturating >> the mempool would be able to stall dm_wait_for_completeion(), no? Eh >> well, it's a separate issue, I guess. > > Your understanding is correct, dm_wait_for_completion() for flush > will stall in such cases for request-based dm. > That's why I mentioned below in > https://www.redhat.com/archives/dm-devel/2010-August/msg00026.html. > > In other words, current request-based device-mapper can't handle > other requests while a flush request is in progress. > > In flush request handling, request-based dm uses dm_wait_for_completion() > to wait for the completion of cloned flush requests, depending on > the fact that there should be only flush requests in flight owning > to the block layer sequencing. I see. bio based implementation also uses dm_wait_for_completion() but it also has DMF_QUEUE_IO_TO_THREAD to plug all the follow up bio's while flush is in progress, which sucks for throughput but successfully avoids starvation. > It's not a separate issue and we need to resolve it at least. > I'm still considering how I can fix the request-based dm. Right, I thought you were talking about REQ_FLUSHes not sycnhronized against barrier write. Anyways, yeah, it's a problem. I don't think not being able to handle multiple flushes concurrently would be a major issue. The problem is not being able to process other bios/requests while a flush is in progress. All that's necessary is making the completion detection a bit more fine grained so that it counts the number of in flight flush bios/requests and completes when it reaches zero instead of waiting for all outstanding commands. Shouldn't be too hard. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
