Messages in this thread | | | Date | Mon, 28 Dec 2020 09:33:44 +0800 | From | Can Guo <> | Subject | Re: [PATCH v1] scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL |
| |
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 >>
| |