lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 28 Dec 2020 09:33:44 +0800 From: Can Guo <cang@...eaurora.org> To: Stanley Chu <stanley.chu@...iatek.com> Cc: Bean Huo <huobean@...il.com>, Avri Altman <Avri.Altman@....com>, linux-scsi@...r.kernel.org, martin.petersen@...cle.com, alim.akhtar@...sung.com, jejb@...ux.ibm.com, beanhuo@...ron.com, asutoshd@...eaurora.org, matthias.bgg@...il.com, bvanassche@....org, linux-mediatek@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, kuohong.wang@...iatek.com, peter.wang@...iatek.com, chun-hung.wu@...iatek.com, andy.teng@...iatek.com, chaotian.jing@...iatek.com, cc.chou@...iatek.com, jiajie.hao@...iatek.com, alice.chao@...iatek.com 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 >>
Powered by blists - more mailing lists