Linux-SCSI Archive on lore.kernel.org
 help / color / Atom feed
From: Avri Altman <Avri.Altman@wdc.com>
To: "daejun7.park@samsung.com" <daejun7.park@samsung.com>,
	Bean Huo <huobean@gmail.com>,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
	"stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
	"cang@codeaurora.org" <cang@codeaurora.org>,
	"bvanassche@acm.org" <bvanassche@acm.org>,
	"tomas.winkler@intel.com" <tomas.winkler@intel.com>,
	ALIM AKHTAR <alim.akhtar@samsung.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Sang-yoon Oh <sangyoon.oh@samsung.com>,
	Sung-Jun Park <sungjun07.park@samsung.com>,
	yongmyung lee <ymhungry.lee@samsung.com>,
	Jinyoung CHOI <j-young.choi@samsung.com>,
	Adel Choi <adel.choi@samsung.com>,
	BoRam Shin <boram.shin@samsung.com>
Subject: RE: [RFC PATCH v3 0/5] scsi: ufs: Add Host Performance Booster Support
Date: Tue, 30 Jun 2020 06:39:27 +0000
Message-ID: <SN6PR04MB46409E7CE538F158387615A6FC6F0@SN6PR04MB4640.namprd04.prod.outlook.com> (raw)
In-Reply-To: <231786897.01593479281798.JavaMail.epsvc@epcpadp2>

Hi,
 
> 
> Hi Bean,
> > On Mon, 2020-06-29 at 15:15 +0900, Daejun Park wrote:
> > > > Seems you intentionally ignored to give you comments on my
> > > > suggestion.
> > > > let me provide the reason.
> > >
> > > Sorry! I replied to your comment (
> > > https://protect2.fireeye.com/url?k=be575021-e3854728-be56db6e-
> 0cc47a31cdf8-
> 6c7d0e1e42762b92&q=1&u=https%3A%2F%2Flkml.org%2Flkml%2F2020%2F6%
> 2F15%2F1492),
> > > but you didn't reply on that. I thought you agreed because you didn't
> > > send
> > > any more comments.
> > >
> > >
> > > > Before submitting your next version patch, please check your L2P
> > > > mapping HPB reqeust submission logical algorithem. I have did
> > >
> > > We are also reviewing the code that you submitted before.
> > > It seems to be a performance improvement as it sends a map request
> > > directly.
> > >
> > > > performance comparison testing on 4KB, there are about 13%
> > > > performance
> > > > drop. Also the hit count is lower. I don't know if this is related
> > > > to
> > >
> > > It is interesting that there is actually a performance improvement.
> > > Could you share the test environment, please? However, I think
> > > stability is
> > > important to HPB driver. We have tested our method with the real
> > > products and
> > > the HPB 1.0 driver is based on that.
> >
> > I just run fio benchmark tool with --rw=randread, --bs=4kb, --
> > size=8G/10G/64G/100G. and see what performance diff with the direct
> > submission approach.
> 
> Thanks!
> 
> > > After this patch, your approach can be done as an incremental patch?
> > > I would
> > > like to test the patch that you submitted and verify it.
> > >
> > > > your current work queue scheduling, since you didn't add the timer
> > > > for
> > > > each HPB request.
> > >
> >
> > Taking into consideration of the HPB 2.0, can we submit the HPB write
> > request to the SCSI layer? if not, it will be a direct submission way.
> > why not directly use direct way? or maybe you have a more advisable
> > approach to work around this. would you please share with us.
> > appreciate.
> 
> I am considering a direct submission way for the next version.
> We will implement the write buffer command of HPB 2.0, after patching HPB
> 1.0.
> 
> As for the direct submission of HPB releated command including HPB write
> buffer, I think we'd better discuss the right approach in depth before
> moving on to the next step.
I vote to stay with the current implementation because:
1) Bean is probably right about 2.0, but it's out of scope for now - 
    there is a long way to go before we'll need to worry about it
2) For now, we should focus on the functional flows. 
    Performance issues, should such issues indeed exists, can be dealt with  later.  And,
3) The current code base is running in production for more than 3 years now.
     I am not so eager to dump a robust, well debugged code unless it absolutely necessary.

Thanks,
Avri



  reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200623010201epcms2p11aebdf1fbc719b409968cba997507114@epcms2p1>
2020-06-23  1:02 ` Daejun Park
     [not found]   ` <CGME20200623010201epcms2p11aebdf1fbc719b409968cba997507114@epcms2p5>
2020-06-23  3:50     ` [RFC PATCH v3 1/5] scsi: ufs: Add UFS feature related parameter Daejun Park
     [not found]   ` <CGME20200623010201epcms2p11aebdf1fbc719b409968cba997507114@epcms2p2>
2020-06-23  3:54     ` [RFC PATCH v3 2/5] scsi: ufs: Add UFS-feature layer Daejun Park
     [not found]   ` <CGME20200623010201epcms2p11aebdf1fbc719b409968cba997507114@epcms2p6>
2020-06-23  3:56     ` [RFC PATCH v3 3/5] scsi: ufs: Introduce HPB module Daejun Park
     [not found]   ` <CGME20200623010201epcms2p11aebdf1fbc719b409968cba997507114@epcms2p7>
2020-06-23  4:03     ` [RFC PATCH v3 4/5] scsi: ufs: L2P map management for HPB read Daejun Park
2020-06-24  9:08       ` Avri Altman
     [not found]       ` <CGME20200623010201epcms2p11aebdf1fbc719b409968cba997507114@epcms2p3>
2020-06-25  0:18         ` Daejun Park
2020-06-29  6:15         ` [RFC PATCH v3 0/5] scsi: ufs: Add Host Performance Booster Support Daejun Park
2020-06-29 11:25           ` Bean Huo
2020-06-28 12:26   ` Bean Huo
2020-06-29  5:24     ` Avri Altman
2020-06-29 10:53       ` Bean Huo
2020-06-29 11:06         ` Avri Altman
2020-06-29 11:39           ` Bean Huo
2020-06-29  5:17   ` Avri Altman
2020-06-23  4:23 ` [RFC PATCH v3 5/5] scsi: ufs: Prepare HPB read for cached sub-region Daejun Park
2020-06-30  1:05 ` [RFC PATCH v3 0/5] scsi: ufs: Add Host Performance Booster Support Daejun Park
2020-06-30  6:39   ` Avri Altman [this message]
2020-06-30 21:59     ` Bean Huo
2020-07-01  1:54     ` Alim Akhtar
2020-06-30 22:05   ` Bean Huo
2020-07-01  0:14 ` 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=SN6PR04MB46409E7CE538F158387615A6FC6F0@SN6PR04MB4640.namprd04.prod.outlook.com \
    --to=avri.altman@wdc.com \
    --cc=adel.choi@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --cc=boram.shin@samsung.com \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=daejun7.park@samsung.com \
    --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=sangyoon.oh@samsung.com \
    --cc=stanley.chu@mediatek.com \
    --cc=sungjun07.park@samsung.com \
    --cc=tomas.winkler@intel.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

Linux-SCSI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-scsi/0 linux-scsi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-scsi linux-scsi/ https://lore.kernel.org/linux-scsi \
		linux-scsi@vger.kernel.org
	public-inbox-index linux-scsi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-scsi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git