All of lore.kernel.org
 help / color / mirror / Atom feed
From: Can Guo <cang@codeaurora.org>
To: Stanley Chu <stanley.chu@mediatek.com>
Cc: jiajie.hao@mediatek.com, Bean Huo <huobean@gmail.com>,
	linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
	andy.teng@mediatek.com, jejb@linux.ibm.com,
	chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com,
	linux-kernel@vger.kernel.org, cc.chou@mediatek.com,
	Avri Altman <Avri.Altman@wdc.com>,
	alice.chao@mediatek.com, linux-mediatek@lists.infradead.org,
	peter.wang@mediatek.com, alim.akhtar@samsung.com,
	matthias.bgg@gmail.com, asutoshd@codeaurora.org,
	chaotian.jing@mediatek.com, bvanassche@acm.org,
	linux-arm-kernel@lists.infradead.org, beanhuo@micron.com
Subject: Re: [PATCH v1] scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
Date: Mon, 28 Dec 2020 09:33:44 +0800	[thread overview]
Message-ID: <ed467feb9c692896ddffe3c36e0dbced@codeaurora.org> (raw)
In-Reply-To: <1608817657.14045.30.camel@mtkswgap22>

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

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
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
Date: Mon, 28 Dec 2020 09:33:44 +0800	[thread overview]
Message-ID: <ed467feb9c692896ddffe3c36e0dbced@codeaurora.org> (raw)
In-Reply-To: <1608817657.14045.30.camel@mtkswgap22>

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

  parent reply	other threads:[~2020-12-28  1:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-22  7:29 [PATCH v1] scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL Stanley Chu
2020-12-22  7:29 ` Stanley Chu
2020-12-22  7:29 ` Stanley Chu
2020-12-22 11:34 ` Can Guo
2020-12-22 11:34   ` Can Guo
2020-12-23  4:19   ` Stanley Chu
2020-12-23  4:19     ` Stanley Chu
2020-12-23  4:19     ` Stanley Chu
2020-12-23  4:41     ` Can Guo
2020-12-23  4:41       ` Can Guo
2020-12-23  7:47       ` Avri Altman
2020-12-23  7:47         ` Avri Altman
2020-12-23  7:47         ` Avri Altman
2020-12-23  8:35         ` Bean Huo
2020-12-23  8:35           ` Bean Huo
2020-12-23  8:35           ` Bean Huo
2020-12-28 12:59         ` Avri Altman
2020-12-28 12:59           ` Avri Altman
2020-12-28 12:59           ` Avri Altman
2020-12-24  2:21       ` Can Guo
2020-12-24  2:21         ` Can Guo
2020-12-24  7:52         ` Stanley Chu
2020-12-24  7:52           ` Stanley Chu
2020-12-24  7:52           ` Stanley Chu
2020-12-24 11:03           ` Avri Altman
2020-12-24 11:03             ` Avri Altman
2020-12-24 11:03             ` Avri Altman
2020-12-24 12:01             ` Bean Huo
2020-12-24 12:01               ` Bean Huo
2020-12-24 12:01               ` Bean Huo
2020-12-24 13:47               ` Stanley Chu
2020-12-24 13:47                 ` Stanley Chu
2020-12-24 13:47                 ` Stanley Chu
2020-12-28  1:32                 ` Asutosh Das (asd)
2020-12-28  1:32                   ` Asutosh Das (asd)
2020-12-28  2:00                   ` Stanley Chu
2020-12-28  2:00                     ` Stanley Chu
2020-12-28  2:00                     ` Stanley Chu
2020-12-28  1:33                 ` Can Guo [this message]
2020-12-28  1:33                   ` Can Guo

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=ed467feb9c692896ddffe3c36e0dbced@codeaurora.org \
    --to=cang@codeaurora.org \
    --cc=Avri.Altman@wdc.com \
    --cc=alice.chao@mediatek.com \
    --cc=alim.akhtar@samsung.com \
    --cc=andy.teng@mediatek.com \
    --cc=asutoshd@codeaurora.org \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=cc.chou@mediatek.com \
    --cc=chaotian.jing@mediatek.com \
    --cc=chun-hung.wu@mediatek.com \
    --cc=huobean@gmail.com \
    --cc=jejb@linux.ibm.com \
    --cc=jiajie.hao@mediatek.com \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=matthias.bgg@gmail.com \
    --cc=peter.wang@mediatek.com \
    --cc=stanley.chu@mediatek.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.