Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 6 Jan 2023 06:51:06 -0800
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
Message-ID: <20230106145106.GA16911@asutoshd-linux1.qualcomm.com>
References: <DM6PR04MB65750DE015FA51FDC08D994BFCFA9@DM6PR04MB6575.namprd04.prod.outlook.com>
 <20221222102121.18682-1-johan+linaro@kernel.org>
 <85e91255-1e6f-f428-5376-08416d2107a2@acm.org>
 <20230104141045.GB8114@asutoshd-linux1.qualcomm.com>
 <3db8c140-2e4e-0d75-4d81-b2c1f22f68d1@acm.org>
 <CGME20230105072134epcas2p47a72da1ee48e341295575770d3eb573c@epcms2p7>
 <20230106022456epcms2p784b3cf9115f6b170bdef0732258381ba@epcms2p7>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Disposition: inline
In-Reply-To: <20230106022456epcms2p784b3cf9115f6b170bdef0732258381ba@epcms2p7>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

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.
>