Hi Linus,
Thanks for getting back on this.
On 12/27/2016 5:51 PM, Linus Walleij wrote:
On Wed, Dec 21, 2016 at 6:22 PM, Ritesh Harjani <riteshh@xxxxxxxxxxxxxx> wrote:
I may have some silly queries here. Please bear with my little understanding
on blk-mq.
It's OK we need to build consensus.
On 12/20/2016 7:31 PM, Linus Walleij wrote:
This hack switches the MMC/SD subsystem from using the legacy blk
layer to using blk-mq. It does this by registering one single
hardware queue, since MMC/SD has only one command pipe. I kill
Could you please confirm on this- does even the HW/SW CMDQ in emmc would use
only 1 hardware queue with (say ~31) as queue depth, of that HW queue? Is
this understanding correct?
Yes as far as I can tell.
Ok.
But you may have to tell me, because I'm not an expert in CMDQ.
Multiple queues are for when you can issue different request truly parallel
without taking any previous and later request into account. CMDQ on
MMC seems to require rollback etc if any of the issued requests after
a certain request fail, and then it is essentially one queue, like a pipeline,
and if one request fails all requests after that request needs to be backed
out, correct?
This depends. There is a command CMD48 which can knock off the error'd
out task from the queue. But in case if the reset of controller and card
is required(for some error) then yes, all requests in queue needs to be
re-queued back and removed from the card queue.
Also there are certain CMDs which can be *only* issued while the queue
of emmc is empty. Otherwise they will be treated as illegal commands.
So yes, there is a dependency in previously issued requests - which
means (as you said) that for blk-mq we should consider in HW/SW CMDQ as
1 HW queue with certain qdepth advertised by card.
Or will it be possible to have more than 1 HW Queue with lesser queue depth
per HW queue?
Depends on the above.
Each queue must have its own error handling, and work isolated from
the other queues to be considered a real hardware queue.
If the requests have dependencies, like referring each other, or
as pointed out, needing to be cancelled if there is an error on a totally
different request, it is just a deep pipeline, single hardware queue.
Yes, thanks for explaining. Agree.
I understand that the block drivers are moving to blk-mq framework.
But keeping that reason apart, do we also anticipate any theoretical
performance gains in moving mmc driver to blk-mq framework - for both in
case of legacy emmc, and SW/HW CMDQ in emmc ? And by how much?
On the contrary we expect a performance regression as mq has no
scheduling. MQ is created for the usecase where you have multiple
hardware queues and they are so hungry for work that you have a problem
feeding them all. Needless to say, on eMMC/SD we don't have that problem
right now atleast.
Ok. Could you please elaborate how a regression?
From very little understanding on blk-mq, I see that it does have
plugging mechanism in place. So merging wont be a problem for most of
the use cases right?
So are you referring to priority given to sync requests v/s async or
idle type requests, which were taken care in CFQ ?
For my own understanding, I would like to understand under what
scenarios or why we should expect a performance regression in blk-mq for
mmc driver without blk-mq scheduling?
It would be even better to know if adding of scheduler to blk-mq will make
any difference in perf gains or not in this case?
The tentative plan as I see it is to shunt in BFQ as the default scheduler
for MQ in the single-hw-queue case. The old block layer schedulers getting
deprecated in the process. But this is really up to the block layer developers.
Ok. Yes, I do see blk-mq scheduling patches on the mailing lists.
Do we any rough estimate or study on that?
This is only out of curiosity and for information purpose.
No it is a venture into the unknown to go where no man has gone before.
I just have a good feeling about this and confidence that it will work out.
So I am doing RFD patches like this one to see if I'm right.
Thanks!!
Regards
Ritesh
Yours,
Linus Walleij
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
