linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Can Guo <cang@codeaurora.org>
To: Bean Huo <huobean@gmail.com>
Cc: Avri Altman <Avri.Altman@wdc.com>,
	daejun7.park@samsung.com, Greg KH <gregkh@linuxfoundation.org>,
	jejb@linux.ibm.com, martin.petersen@oracle.com,
	asutoshd@codeaurora.org, stanley.chu@mediatek.com,
	bvanassche@acm.org, ALIM AKHTAR <alim.akhtar@samsung.com>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sung-Jun Park <sungjun07.park@samsung.com>,
	yongmyung lee <ymhungry.lee@samsung.com>,
	Jinyoung CHOI <j-young.choi@samsung.com>,
	BoRam Shin <boram.shin@samsung.com>,
	SEUNGUK SHIN <seunguk.shin@samsung.com>
Subject: Re: [PATCH v19 3/3] scsi: ufs: Prepare HPB read for cached sub-region
Date: Sun, 07 Feb 2021 15:36:04 +0800	[thread overview]
Message-ID: <ba7943ab40720df96a9fedb04ab0e4c8@codeaurora.org> (raw)
In-Reply-To: <12a011cd895dc9be5ec6c4f964b6011af492f06d.camel@gmail.com>

On 2021-02-05 23:08, Bean Huo wrote:
> On Fri, 2021-02-05 at 14:06 +0000, Avri Altman wrote:
>> > > > +     put_unaligned_be64(ppn, &cdb[6]);
>> > >
>> > > You are assuming the HPB entries read out by "HPB Read Buffer"
>> > > cmd
>> > > are
>> > > in Little
>> > > Endian, which is why you are using put_unaligned_be64 here.
>> > > However,
>> > > this assumption
>> > > is not right for all the other flash vendors - HPB entries read
>> > > out
>> > > by
>> > > "HPB Read Buffer"
>> > > cmd may come in Big Endian, if so, their random read performance
>> > > are
>> > > screwed.
>> >
>> > For this question, it is very hard to make a correct format since
>> > the
>> > Spec doesn't give a clear definition. Should we have a default
>> > format,
>> > if there is conflict, and then add quirk or add a vendor-specific
>> > table?
>> >
>> > Hi Avri
>> > Do you have a good idea?
>> 
>> I don't know.  Better let Daejun answer this.
>> This was working for me for both Galaxy S20 (Exynos) as well as
>> Xiaomi Mi10 (8250).
>> 
> 
> Thanks, I tested Daejun's patchset before, it is also ok (I don't know
> which version patchset). maybe we can keep current implementation as
> default, then if there is conflict, and submit the quirk.
> 

Yeah, you've tested it, are you sure that Micron's UFS devices are OK
with this specific code line?

Micron UFS FW team has confirmed that Micron's HPB entries read out by
"HPB Buffer Read" cmd are in big-endian byte ordering.

If Micron FW team is right, I am pretty sure that you would have seen
random read performance regression on Micron UFS devices caused by
invalid HPB entry format in HPB Read cmd UPIU (which leads to L2P cache
miss in device side all the time) during your test.

Can Guo.

> Thanks,
> Bean
> 
>> Thanks,
>> Avri

  reply	other threads:[~2021-02-07  7:37 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p6>
2021-01-29  5:28 ` [PATCH v19 0/3] scsi: ufs: Add Host Performance Booster Support Daejun Park
     [not found]   ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p3>
2021-01-29  5:30     ` [PATCH v19 2/3] scsi: ufs: L2P map management for HPB read Daejun Park
2021-02-05 11:15       ` Bean Huo
2021-02-05 11:42         ` Avri Altman
2021-02-05 11:54           ` Bean Huo
     [not found]           ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p2>
2021-02-08  8:00             ` Daejun Park
2021-02-06  7:23       ` Can Guo
2021-02-06  9:14         ` Bean Huo
2021-02-06 19:17         ` Avri Altman
2021-02-08  7:21       ` Can Guo
     [not found]   ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p5>
2021-01-29  5:30     ` [PATCH v19 3/3] scsi: ufs: Prepare HPB read for cached sub-region Daejun Park
2021-02-05  3:29       ` Can Guo
2021-02-05 12:35         ` Bean Huo
2021-02-05 14:06           ` Avri Altman
2021-02-05 15:08             ` Bean Huo
2021-02-07  7:36               ` Can Guo [this message]
2021-02-07 10:44                 ` Bean Huo
2021-02-09 13:25             ` Avri Altman
2021-02-09 14:21               ` Bean Huo
2021-02-10  5:32                 ` Can Guo
2021-02-08  8:16         ` Bean Huo
2021-02-08  9:58           ` Can Guo
2021-02-10  9:36       ` Avri Altman
2021-02-08  8:03     ` Re: [PATCH v19 2/3] scsi: ufs: L2P map management for HPB read Daejun Park
2021-02-08  8:34       ` Can Guo
     [not found]   ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p1>
2021-01-29  5:29     ` [PATCH v19 1/3] scsi: ufs: Introduce HPB feature Daejun Park
2021-02-02  7:46       ` Avri Altman
2021-02-02 11:12         ` Greg KH
2021-02-08  8:53     ` Re: [PATCH v19 2/3] scsi: ufs: L2P map management for HPB read Daejun Park
2021-02-08  9:23       ` Can Guo
     [not found]       ` <CGME20210129052848epcms2p6e5797efd94e6282b76ad9ae6c99e3ab5@epcms2p8>
2021-02-09  1:27         ` Daejun Park
2021-02-09  2:28           ` Can Guo
2021-02-08  8:01 ` Daejun Park

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=ba7943ab40720df96a9fedb04ab0e4c8@codeaurora.org \
    --to=cang@codeaurora.org \
    --cc=Avri.Altman@wdc.com \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --cc=boram.shin@samsung.com \
    --cc=bvanassche@acm.org \
    --cc=daejun7.park@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=huobean@gmail.com \
    --cc=j-young.choi@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=seunguk.shin@samsung.com \
    --cc=stanley.chu@mediatek.com \
    --cc=sungjun07.park@samsung.com \
    --cc=ymhungry.lee@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).