public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Kiwoong Kim" <kwmad.kim@samsung.com>
To: <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<alim.akhtar@samsung.com>, <avri.altman@wdc.com>,
	<jejb@linux.ibm.com>, <martin.petersen@oracle.com>,
	<beanhuo@micron.com>, <cang@codeaurora.org>,
	<adrian.hunter@intel.com>, <sc.suh@samsung.com>,
	<hy50.seo@samsung.com>, <sh425.lee@samsung.com>,
	<bhoon95.kim@samsung.com>
Subject: Question about ufs_bsg
Date: Tue, 14 Sep 2021 14:59:06 +0900	[thread overview]
Message-ID: <000001d7a92d$a0edcb00$e2c96100$@samsung.com> (raw)
In-Reply-To: CGME20210914055907epcas2p1c9d5d91c61592a67b9ce4b2a88d8f279@epcas2p1.samsung.com

Hi,

ufs_bsg was introduced nearly three years ago and it allocates its own request queue.
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



       reply	other threads:[~2021-09-14  5:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210914055907epcas2p1c9d5d91c61592a67b9ce4b2a88d8f279@epcas2p1.samsung.com>
2021-09-14  5:59 ` Kiwoong Kim [this message]
2021-09-14  6:39   ` Question about ufs_bsg Avri Altman
2021-09-14  6:45     ` Kiwoong Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001d7a92d$a0edcb00$e2c96100$@samsung.com' \
    --to=kwmad.kim@samsung.com \
    --cc=adrian.hunter@intel.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bhoon95.kim@samsung.com \
    --cc=cang@codeaurora.org \
    --cc=hy50.seo@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sc.suh@samsung.com \
    --cc=sh425.lee@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox