[...] >>> >>> SDHCIv4 has a feature (ADMA3) which is slightly similar to packed >>> commands but it does not require card support. >>> >>> Why is it a problem for blk-mq to allow some extra requests to >>> pick from for packing? >>> >> >> In blk-mq, requests don't get picked from the queue, but instead those >> gets "pushed" to the block device driver. >> >> First, to support packing, it seems like we would need to specify a >> queue-depth > 1, more or less lie to blk-mq layer about the device's >> capability. Okay, we can do that. But.. >> >> I also believe, the implementation would become really complex, as you >> would need to "hold" the first write request, while waiting for a >> second to arrive. Then for how long shall you hold it? And then what >> if you are unlucky so the next is read request, thus you can't pack >> them. The solution will be suboptimal, won't it? > > It doesn't hold and wait now. So why would it in the blk-mq case? Because earlier the mmc block device driver *fetches* requests from the queue and when finding more than one request, we could try to pack them. If there are only one request, we just move on with it. With blk-mq, we don't *fetch* request from the queue, but instead those would get pushed to the mmc block device driver via the implemented block-mq ops. Please note, I am not an blk-mq expert, but this is my understanding. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
