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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
