All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Asutosh Das <asutoshd@codeaurora.org>,
	Avri Altman <avri.altman@wdc.com>, Bean Huo <beanhuo@micron.com>,
	Stanley Chu <stanley.chu@mediatek.com>,
	Can Guo <cang@codeaurora.org>
Subject: Re: [PATCH] scsi: ufs: add a quirk to disable FUA support
Date: Wed, 1 Jun 2022 10:05:45 -0700	[thread overview]
Message-ID: <YpecaXfIxZBHIcfj@google.com> (raw)
In-Reply-To: <d3038c9e-c9ec-16e9-bad4-8b1de5e23ba6@intel.com>

On 06/01, Adrian Hunter wrote:
> On 31/05/22 23:10, Jaegeuk Kim wrote:
> > UFS stack shows very low performance of FUA comparing to write and cache_flush.
> > Let's add a quirk to adjust it.
> > 
> > E.g., average latency according to the chunk size of write
> > 
> > Write(us/KB)	4	64	256	1024	2048
> > FUA		873.792	754.604	995.624	1011.67	1067.99
> > CACHE_FLUSH	824.703	712.98	800.307	1019.5	1037.37
> 
> Wouldn't it depend on how much data might be in the cache?

I've got this average latency from 100 commands of write+cache_flush vs.
write(FUA). I think the cached data should be the same as this chunk
size.

> Do you have real-world use-cases where the difference is measurable?

I'm approaching this based on 1) f2fs uses FUA for checkpoint and fsync,
and 2) iomap uses FUA for O_DIRECT|O_DSYNC case [1].

[1] https://lore.kernel.org/lkml/20220527205955.3251982-1-jaegeuk@kernel.org/

> 
> > 
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >  drivers/scsi/ufs/ufshcd.c | 3 +++
> >  drivers/scsi/ufs/ufshcd.h | 5 +++++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index 3f9caafa91bf..811f3467879c 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -5035,6 +5035,9 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
> >  	 */
> >  	sdev->silence_suspend = 1;
> >  
> > +	if (hba->quirks & UFSHCD_QUIRK_BROKEN_FUA)
> > +		sdev->broken_fua = 1;
> > +
> >  	ufshcd_crypto_register(hba, q);
> >  
> >  	return 0;
> > diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> > index 94f545be183a..6c480c6741d6 100644
> > --- a/drivers/scsi/ufs/ufshcd.h
> > +++ b/drivers/scsi/ufs/ufshcd.h
> > @@ -602,6 +602,11 @@ enum ufshcd_quirks {
> >  	 * support physical host configuration.
> >  	 */
> >  	UFSHCD_QUIRK_SKIP_PH_CONFIGURATION		= 1 << 16,
> > +
> > +	/*
> > +	 * This quirk disables FUA support.
> > +	 */
> > +	UFSHCD_QUIRK_BROKEN_FUA				= 1 << 17,
> 
> Wouldn't it be more appropriate to make it a UFS_DEVICE_QUIRK_
> since it presumably depends on the UFS device not the host controller?
> 
> Also, as already commented by others, there needs to be a user of
> the quirk

Since I asked SoC vendors can verify the performance with this quirk,
I need to wait for their reply. Meanwhile, I'm willing to disable FUA in Pixel
devices, which I cannot post any patch directly to LKML.

Agreed that, if there's no other user in upstream, I'm okay to drop
this.

> 
> >  };
> >  
> >  enum ufshcd_caps {

      parent reply	other threads:[~2022-06-01 17:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-31 20:10 [PATCH] scsi: ufs: add a quirk to disable FUA support Jaegeuk Kim
2022-05-31 20:34 ` Eric Biggers
2022-05-31 20:53   ` Jaegeuk Kim
2022-05-31 21:25     ` Eric Biggers
2022-06-07 16:45       ` Asutosh Das
2022-06-01  5:24 ` Adrian Hunter
2022-06-01 11:59   ` Bart Van Assche
2022-06-01 17:06     ` Jaegeuk Kim
2022-06-01 17:05   ` Jaegeuk Kim [this message]

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=YpecaXfIxZBHIcfj@google.com \
    --to=jaegeuk@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=asutoshd@codeaurora.org \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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.