* Question about cmd_queue
[not found] <CGME20210914060836epcas2p2cf299639dba0abd11cdbe75534c9b9c9@epcas2p2.samsung.com>
@ 2021-09-14 6:08 ` Kiwoong Kim
0 siblings, 0 replies; only message in thread
From: Kiwoong Kim @ 2021-09-14 6:08 UTC (permalink / raw)
To: linux-scsi, linux-kernel, alim.akhtar, avri.altman, jejb,
martin.petersen, beanhuo, cang, adrian.hunter, sc.suh, hy50.seo,
sh425.lee, bhoon95.kim
> ufs_bsg was introduced nearly three years ago and it allocates its own
> request queue.
This is not related with ufs_bsg. I want to talk about a member under ufs_hba, cmd_queue.
Very sorry for making you confused.
> I faced a sytmpom with this and want to ask something about it.
>
> That is, sometimes queue depth for ufs is limited to half of the its
> maximum value even in a situation with many IO requests from filesystem.
> It turned out that it only occurs when a query is being processed at the
> same time.
> Regarding my tracing, when the query process starts, users for the hctx
> that represents a ufs host increase to two and with this, some pathes
> calling 'hctx_may_queue'
> function in blk-mq seems to throttle dispatches, technically with 16
> because the number of ufs slots (32 in my case) is dividend by two (users).
>
> I found that it happened when a query for write booster is processed
> because write booster only turns on in some conditions in my base that is
> different from kernel mainline. But when an exceptional event or others
> that could lead to a query occurs, it can happen even in mainline.
>
> I think the throttling is a little bit excessive, so the question: is
> there any way to assign queue depth per user on an asymmetric basis?
>
> Thanks.
> Kiwoong Kim
^ permalink raw reply [flat|nested] only message in thread