Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Mime-Version: 1.0
Subject: Re: [RFC PATCH v3 0/5] scsi: ufs: Add Host Performance Booster
 Support
Reply-To: daejun7.park@samsung.com
From:   Daejun Park <daejun7.park@samsung.com>
To:     Bean Huo <huobean@gmail.com>,
        Daejun Park <daejun7.park@samsung.com>,
        "avri.altman@wdc.com" <avri.altman@wdc.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>
In-Reply-To: <948f573d136b39410f7d610e5019aafc9c04fe62.camel@gmail.com>
Message-ID: <336371513.41593411482259.JavaMail.epsvc@epcpadp2>
Date:   Mon, 29 Jun 2020 15:15:46 +0900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
References: <948f573d136b39410f7d610e5019aafc9c04fe62.camel@gmail.com>
        <963815509.21592879582091.JavaMail.epsvc@epcpadp2>
        <CGME20200623010201epcms2p11aebdf1fbc719b409968cba997507114@epcms2p3>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> Seems you intentionally ignored to give you comments on my suggestion.
> let me provide the reason.
Sorry! I replied to your comment (https://lkml.org/lkml/2020/6/15/1492),
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.
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.
There was Bart's comment that it was not good add an arbitrary timeout value
to the request. (please refer to: https://lkml.org/lkml/2020/6/11/1043)
When no timer is added to the request, the SD timout will be set as default
timeout at the block layer.

Thanks,
Daejun