public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Asutosh Das <quic_asutoshd@quicinc.com>
To: Jinyoung CHOI <j-young.choi@samsung.com>
Cc: Avri Altman <Avri.Altman@wdc.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Johan Hovold <johan+linaro@kernel.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"ALIM AKHTAR" <alim.akhtar@samsung.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Can Guo <quic_cang@quicinc.com>
Subject: Re: (2) [PATCH] scsi: ufs: core: fix devfreq deadlocks
Date: Fri, 6 Jan 2023 06:51:06 -0800	[thread overview]
Message-ID: <20230106145106.GA16911@asutoshd-linux1.qualcomm.com> (raw)
In-Reply-To: <20230106022456epcms2p784b3cf9115f6b170bdef0732258381ba@epcms2p7>

On Fri, Jan 06 2023 at 18:25 -0800, Jinyoung CHOI wrote:
>>> On 1/4/23 06:10, Asutosh Das wrote:
>>> > Load based toggling of WB seemed fine to me then.
>>> > I haven't thought about another method to toggle WriteBooster yet.
>>> > Let me see if I can come up with something.
>>> > IMT if you have a mechanism in mind, please let me know.
>>>
>>> Hi Asutosh,
>>>
>>> Which UFS devices need this mechanism? All UFS devices I'm familiar with can
>>> achieve wire speed for large write requests without enabling the WriteBooster.
>>This feature assures SLC-performance for writes to the WriteBooster buffer.
>>So enabling it is advantageous as far as write performance.
>
>I agree with you. Also, it can be used in various ways.
>
>>As for the toggling functionality, compared to e.g. enabling it on init and leave it on,
>>some flash vendors require it because of device health considerations.
>>This is not the case for us, so let others to comment.
>
>In our case, it does not matter whether to toggle or not.
>To make the code simple, it seems to be a good way to enable it on init and leave it on.
>Considering device health, WB can be disabled through lifetime check.
>
>Thanks,
>Jinyoung.
>
Hi Jinyoung / Avri / Bart

My understanding during the WriteBooster development was that the endurance of
the SLC buffer is considerably less and hence it's *not* a good idea to always
keep it ON. From the spec,
"
7279 Whenever the endurance of the WriteBooster Buffer is consumed completely, a write command is
7280 processed as if WriteBooster feature was disabled. Therefore, it is recommended to set fWriteBoosterEn to
7281 one, only when WriteBooster performance is needed, so that WriteBooster feature can be used for a longer
7282 time.
"
Going by this toggling it to ON when the load is high and performance is needed seemed reasonable.

Now then, if you confirm that there's no considerable difference in the WB buffer lifetime by
either always keeping it on at init OR on-demand, then this toggle code should be removed.
I will talk to other UFS device vendors who may not be active in this list and get back.

-asd

>>
>>Thanks,
>>Avri
>>>
>>> Thanks,
>>>
>>> Bart.
>

  reply	other threads:[~2023-01-06 14:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 10:21 [PATCH] scsi: ufs: core: fix devfreq deadlocks Johan Hovold
2023-01-03 21:28 ` Andrew Halaney
2023-01-03 21:45 ` Bart Van Assche
2023-01-04  8:24   ` Avri Altman
2023-01-04 22:34     ` Bart Van Assche
2023-01-04 14:10   ` Asutosh Das
2023-01-04 22:31     ` Bart Van Assche
2023-01-05  7:21       ` Avri Altman
2023-01-06  2:24         ` Jinyoung CHOI
2023-01-06 14:51           ` Asutosh Das [this message]
2023-01-05 18:38 ` Bart Van Assche
2023-01-16 16:03   ` Johan Hovold

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=20230106145106.GA16911@asutoshd-linux1.qualcomm.com \
    --to=quic_asutoshd@quicinc.com \
    --cc=Avri.Altman@wdc.com \
    --cc=alim.akhtar@samsung.com \
    --cc=bvanassche@acm.org \
    --cc=j-young.choi@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=johan+linaro@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=quic_cang@quicinc.com \
    --cc=stable@vger.kernel.org \
    /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