Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: cang=codeaurora.org@mg.codeaurora.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Mon, 28 Dec 2020 09:33:44 +0800
From:   Can Guo <cang@codeaurora.org>
To:     Stanley Chu <stanley.chu@mediatek.com>
Cc:     Bean Huo <huobean@gmail.com>, Avri Altman <Avri.Altman@wdc.com>,
        linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
        alim.akhtar@samsung.com, jejb@linux.ibm.com, beanhuo@micron.com,
        asutoshd@codeaurora.org, matthias.bgg@gmail.com,
        bvanassche@acm.org, linux-mediatek@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        kuohong.wang@mediatek.com, peter.wang@mediatek.com,
        chun-hung.wu@mediatek.com, andy.teng@mediatek.com,
        chaotian.jing@mediatek.com, cc.chou@mediatek.com,
        jiajie.hao@mediatek.com, alice.chao@mediatek.com
Subject: Re: [PATCH v1] scsi: ufs-mediatek: Enable
 UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
In-Reply-To: <1608817657.14045.30.camel@mtkswgap22>
References: <20201222072928.32328-1-stanley.chu@mediatek.com>
 <c862866ec97516a7ffb891e5de3d132d@codeaurora.org>
 <1608697172.14045.5.camel@mtkswgap22>
 <c83d34ca8b0338526f6440f1c4ee43dd@codeaurora.org>
 <ff8efda608e6f95737a675ee03fa3ca2@codeaurora.org>
 <1608796334.14045.21.camel@mtkswgap22>
 <DM6PR04MB6575D0DD2C04692AEF771494FCDD0@DM6PR04MB6575.namprd04.prod.outlook.com>
 <5eb12622222bd9ba5e705801a204f3160ba3966b.camel@gmail.com>
 <1608817657.14045.30.camel@mtkswgap22>
Message-ID: <ed467feb9c692896ddffe3c36e0dbced@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk

On 2020-12-24 21:47, Stanley Chu wrote:
> Hi Avri, Bean,
> 
> On Thu, 2020-12-24 at 13:01 +0100, Bean Huo wrote:
>> On Thu, 2020-12-24 at 11:03 +0000, Avri Altman wrote:
>> > > > Do you see any substantial benefit of having
>> > > > fWriteBoosterBufferFlushEn
>> > > > disabled?
>> > >
>> > > 1. The definition of fWriteBoosterBufferFlushEn is that host allows
>> > > device to do flush in anytime after fWriteBoosterBufferFlushEn is
>> > > set as
>> > > on. This is not what we want.
>> > >
>> > > Just Like BKOP, We do not want flush happening beyond host's
>> > > expected
>> > > timing that device performance may be "randomly" dropped.
>> >
>> > Explicit flush takes place only when the device is idle:
>> > if fWriteBoosterBufferFlushEn is set, the device is idle, and before
>> > h8 received.
>> > If a request arrives, the flush operation should be halted.
>> > So no performance degradation is expected.
>> 
>> Hi Stanley
>> 
>> Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will
>> flush only when it is in idle, once there is new incoming request, the
>> flush will be suspended. You should be very careful when you want to
>> skip this stetting of this flag.
> 
> Very appreciate your the clarification.
> 
> However similar to "Background Operations Termination Latency", while
> the next request comes, device may need some time to suspend on-going
> flush operations. This delay may "randomly" degrade the performance
> right?

That can be case by case (or vendor by vendor), but generally I agree
with you on this.

> 
> Since the configuration, i.e., enable
> fWriteBoosterBufferFlushDuringHibernate only with
> fWriteBoosterBufferFlushEn disabled, has been applied in many of our
> mass-produced products these yeas, we would like to keep it unless the
> new setting has obvious benefits.

Thanks for sharing the info. I will leave the decision to Asutosh on 
this.

Thanks,
Can Guo.

> 
> Thanks,
> Stanley Chu
> 
>> 
>> Bean
>>