From: Daejun Park <daejun7.park@samsung.com>
To: Avri Altman <Avri.Altman@wdc.com>,
Daejun Park <daejun7.park@samsung.com>,
ALIM AKHTAR <alim.akhtar@samsung.com>,
"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
"beanhuo@micron.com" <beanhuo@micron.com>,
"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>
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 4/5] scsi: ufs: L2P map management for HPB read
Date: Tue, 09 Jun 2020 09:52:56 +0900 [thread overview]
Message-ID: <1776409896.101591664283293.JavaMail.epsvc@epcpadp2> (raw)
In-Reply-To: <SN6PR04MB46409E16CCF95A0AA9FFE944FC870@SN6PR04MB4640.namprd04.prod.outlook.com>
> > The data structure for map data request and L2P map uses mempool API,
> > minimizing allocation overhead while avoiding static allocation.
> Maybe one or two more sentences to explain the L2P framework:
> Each hpb lun maintains 2 "to-do" lists:
> - hpb->lh_inact_rgn - regions to be inactivated, and
> - hpb->lh_act_srgn - subregions to be activated
> Those lists are being checked on every resume and completion interrupt.
OK, I will add more description of L2P framework.
> >
> > Signed-off-by: Daejun Park <daejun7.park@samsung.com>
> > ---
> > + for (i = 0; i < hpb->pages_per_srgn; i++) {
> > + mctx->m_page[i] = mempool_alloc(ufshpb_drv.ufshpb_page_pool,
> > + GFP_KERNEL);
> > + memset(page_address(mctx->m_page[i]), 0, PAGE_SIZE);
> Better move this memset after if (!mctx->m_page[i]).
> And maybe use clear_page instead?
OK, I will change the code.
> > + if (!mctx->m_page[i]) {
> > + for (j = 0; j < i; j++)
> > + mempool_free(mctx->m_page[j],
> > + ufshpb_drv.ufshpb_page_pool);
> > + goto release_ppn_dirty;
> > + }
> > +static inline int ufshpb_add_region(struct ufshpb_lu *hpb,
> > + struct ufshpb_region *rgn)
> > +{
> Maybe better describe what this function does - ufshpb_get_rgn_map_ctx ?
Yes, I think "ufshpb_get_rgn_map_ctx" is better name.
> > + if (!list_empty(&rgn->list_lru_rgn)) {
> > + if (ufshpb_check_issue_state_srgns(hpb, rgn)) {
> So if one of its subregions has inflight map request - you add it to the "starved" list?
> Why call it starved?
"starved list" was wrong name. I will change it to "postponed_evict_list".
> > + * Since the region state change occurs only in the hpb task-work,
> > + * the state of the region cannot HPB_RGN_INACTIVE at this point.
> > + * The region state must be changed in the hpb task-work
> I think that you called this worker map_work?
Yes, "the hpb task-work" will be changed to the map_work.
> > + spin_unlock_irqrestore(&hpb->hpb_state_lock, flags);
> > + ret = ufshpb_add_region(hpb, rgn);
> If this is not an active region,
> Although the device indicated to activate a specific subregion,
> You are activating all the subregions of that region.
> You should elaborate on that in your commit log,
> and explain why this is the correct activation course.
Yes, I'm going to change the code to activate only the subregions that are "activate state".
> get_unaligned instead of be16_to_cpu ?
Yes, I will change.
> > +
> > + if (!data_seg_len) {
> data_seg_len should be DEV_DATA_SEG_LEN, and you should also check HPB_UPDATE_ALERT,
> which you might want to do here and not in ufshpb_may_field_valid
Yes, I will change.
> > + switch (rsp_field->hpb_type) {
> > + case HPB_RSP_REQ_REGION_UPDATE:
> > + WARN_ON(data_seg_len != DEV_DATA_SEG_LEN);
> > + ufshpb_rsp_req_region_update(hpb, rsp_field);
> > + break;
> What about hpb dev reset - oper 0x2?
Yes, I will change.
> > +static void ufshpb_add_active_list(struct ufshpb_lu *hpb,
> > + struct ufshpb_region *rgn,
> > + struct ufshpb_subregion *srgn)
> > +{
> > + if (!list_empty(&rgn->list_inact_rgn))
> > + return;
> > +
> > + if (!list_empty(&srgn->list_act_srgn)) {
> > + list_move(&srgn->list_act_srgn, &hpb->lh_act_srgn);
> Why is this needed?
> Why updating this subregion position?
The "ufshpb_add_active_list()" is called from "ufshpb_run_active_subregion_list()" to retry activating subregion that failed to activate.
Therefore, it requeues the subregion to activate region list head.
> > @@ -195,8 +1047,15 @@ static int ufshpb_alloc_region_tbl(struct ufs_hba
> > *hba, struct ufshpb_lu *hpb)
> > release_srgn_table:
> > for (i = 0; i < rgn_idx; i++) {
> > rgn = rgn_table + i;
> > - if (rgn->srgn_tbl)
> > + if (rgn->srgn_tbl) {
> > + for (srgn_idx = 0; srgn_idx < rgn->srgn_cnt;
> > + srgn_idx++) {
> > + srgn = rgn->srgn_tbl + srgn_idx;
> > + if (srgn->mctx)
> How is it even possible that on init there is an active subregion?
> ufshpb_init_pinned_active_region does its own cleanup.
I will fix the duplicated cleanup codes.
> > + hpb->m_page_cache = kmem_cache_create("ufshpb_m_page_cache",
> > + sizeof(struct page *) * hpb->pages_per_srgn,
> > + 0, 0, NULL);
> What is the advantage in using an array of page pointers,
> Instead of a single pointer to pages_per_srgn?
To minimize memory fragmentation problem, I used pointer + single page rather than single array of pages.
> > @@ -398,6 +1326,9 @@ static void ufshpb_resume(struct ufs_hba *hba)
> >
> > dev_info(&hpb->hpb_lu_dev, "ufshpb resume");
> > ufshpb_set_state(hpb, HPB_PRESENT);
> > + if (!ufshpb_is_empty_rsp_lists(hpb))
> > + queue_work(ufshpb_drv.ufshpb_wq, &hpb->map_work);
> Ahha - so you are using the ufs driver pm flows to poll your work queue.
> Why device recommendations isn't enough?
I don't understand this comment. The code resumes map_work that was stopped by PM during the map request.
Please explain your concerns.
Thanks,
Avri
next prev parent reply other threads:[~2020-06-09 0:58 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200605011604epcms2p8bec8ef6682583d7248dc7d9dc1bfc882@epcms2p8>
2020-06-05 1:16 ` [RFC PATCH 0/5] scsi: ufs: Add Host Performance Booster Support Daejun Park
2020-06-05 1:22 ` [RFC PATCH 1/5] scsi: ufs: Add UFS feature related parameter Daejun Park
2020-06-05 1:30 ` [RFC PATCH 2/5] scsi: ufs: Add UFS-feature layer Daejun Park
2020-06-05 1:38 ` [RFC PATCH 3/5] scsi: ufs: Introduce HPB module Daejun Park
2020-06-05 1:56 ` [RFC PATCH 4/5] scsi: ufs: L2P map management for HPB read Daejun Park
2020-06-05 2:12 ` [RFC PATCH 5/5] scsi: ufs: Prepare HPB read for cached sub-region Daejun Park
2020-06-06 18:38 ` Avri Altman
2020-06-09 0:53 ` Daejun Park
2020-06-09 1:23 ` Bart Van Assche
2020-06-11 1:37 ` Bart Van Assche
2020-06-11 6:43 ` Avri Altman
2020-06-12 3:39 ` Daejun Park
2020-06-06 18:26 ` [RFC PATCH 4/5] scsi: ufs: L2P map management for HPB read Avri Altman
2020-06-09 0:52 ` Daejun Park [this message]
2020-06-09 6:39 ` Avri Altman
2020-06-10 2:49 ` Daejun Park
2020-06-09 6:48 ` Avri Altman
2020-06-10 3:51 ` Daejun Park
2020-06-09 1:15 ` Bart Van Assche
2020-06-11 1:16 ` Bart Van Assche
2020-06-12 3:37 ` Daejun Park
2020-06-13 15:24 ` Bart Van Assche
2020-06-06 14:58 ` [RFC PATCH 3/5] scsi: ufs: Introduce HPB module Avri Altman
2020-06-09 0:52 ` Daejun Park
2020-06-09 6:51 ` Avri Altman
2020-06-12 2:25 ` Daejun Park
2020-06-07 7:06 ` Avri Altman
2020-06-09 0:53 ` Daejun Park
2020-06-10 4:29 ` Bart Van Assche
2020-06-10 9:57 ` Bean Huo
2020-06-12 2:29 ` Daejun Park
2020-06-10 4:15 ` [RFC PATCH 2/5] scsi: ufs: Add UFS-feature layer Bart Van Assche
2020-06-12 2:27 ` Daejun Park
2020-06-12 4:28 ` Bart Van Assche
2020-06-11 1:39 ` Bart Van Assche
2020-06-06 12:11 ` [RFC PATCH 1/5] scsi: ufs: Add UFS feature related parameter Avri Altman
2020-06-09 0:51 ` Daejun Park
2020-06-06 12:02 ` [RFC PATCH 0/5] scsi: ufs: Add Host Performance Booster Support Avri Altman
2020-06-09 0:49 ` Daejun Park
2020-06-09 7:00 ` Avri Altman
2020-06-10 9:50 ` Bean Huo
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=1776409896.101591664283293.JavaMail.epsvc@epcpadp2 \
--to=daejun7.park@samsung.com \
--cc=Avri.Altman@wdc.com \
--cc=adel.choi@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=beanhuo@micron.com \
--cc=boram.shin@samsung.com \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--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
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