Messages in this thread | | | Date | Sat, 26 Oct 2013 04:46:12 -0700 | From | Christoph Hellwig <> | Subject | blk-mq flush fix |
| |
I've just ran into an issue where I ran out of blk-mq tags on my virtio setup on what appears a heavy fsync workload. When drilling it down it seemed to be a tag leak. This reminded me of a commit I had seen in the scsi-mq tree but never on any mailinglist (and neither in my Inbox despite the Cc tag) which turned out to be in Jens' blk-mq tree either.
https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=scsi-mq&id=620fe5a562440a823e7a25ae99dc19a6fbd53949
From a quick look over the patch I'm not entirely sure it's correct, but it's at least going in the right direction. The reason for the issue that Alexander and I saw is the following:
The flush state machine takes in a struct request, which then is submitted multiple times to the underling driver. The old block code requeses the same request for each of those, so it does not have an issue with tapping into the request pool. The new one on the other hand allocates a new request for each of the actualy steps of the flush sequence.
In theory this should make the patch from Alexander the right fix, except that we do have a corner case where we do not do the above steps: In case the state machine doesn't need to be run we issue the request directly. This either happens if the driver doesn't need any cache flushes, or we only requested force unit access and the driver supports that natively.
It seems like we should set simply not require a tag at all for those sub requests and solve the issue that way.
And Alexander and Nick: how did this patch end up in Nick's tree? I'm a bit curious at all as there's been no visibility at all, despite Cc tags to Jens and me.
| |