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;
IronPort-SDR: Ce68C9UPtIZM42SCqaev6zJ4Y5ePtZISLG8BsQIe5kNfnjMye6osSs7JLMbD8hrDjxUHywDJ3M
 sAdfjTFmnwBFBxGLdSVsRSKhr1xPKgZymKHCFPTSIwuQIeov9b1xBj3LugSBuwKfcYpX/fxhMC
 7CaEo1FolqyzHnXyEbV3WdpUAGZ4IK9nS+d5aG6VB7NMOPZ/XCvt3ULiK/3XSoKFKj7x/qP31/
 St5AXZVX0bimM0MEN+HWQ3T9zzQZpUEtwW1XAeb5Jzmx8S1Oq+wuBDsTHGXkcchakJu0grtGiH
 Ew8=
From:   Avri Altman <Avri.Altman@wdc.com>
To:     "yohan.joung@sk.com" <yohan.joung@sk.com>
CC:     "alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
        "asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "cang@codeaurora.org" <cang@codeaurora.org>,
        "d_hyun.kwon@samsung.com" <d_hyun.kwon@samsung.com>,
        "daejun7.park@samsung.com" <daejun7.park@samsung.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "huobean@gmail.com" <huobean@gmail.com>,
        "j-young.choi@samsung.com" <j-young.choi@samsung.com>,
        "jaemyung.lee@samsung.com" <jaemyung.lee@samsung.com>,
        "jaeyoung21.choi@sk.com" <jaeyoung21.choi@sk.com>,
        "javier.gonz@samsung.com" <javier.gonz@samsung.com>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "jh.i.park@samsung.com" <jh.i.park@samsung.com>,
        "jieon.seol@samsung.com" <jieon.seol@samsung.com>,
        "keosung.park@samsung.com" <keosung.park@samsung.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "sungjun07.park@samsung.com" <sungjun07.park@samsung.com>
Subject: RE: [PATCH v37 3/4] scsi: ufs: Prepare HPB read for cached sub-region
Thread-Topic: [PATCH v37 3/4] scsi: ufs: Prepare HPB read for cached
 sub-region
Thread-Index: Addgq8fAZ5jjWmnhQIC9oaNz2KTkmwAPPcJg
Date:   Mon, 14 Jun 2021 06:48:31 +0000
Message-ID: <DM6PR04MB65752F72F99EFF4BD41A4B0EFC319@DM6PR04MB6575.namprd04.prod.outlook.com>
References: <d38fbfa83d1f421c8a0d201a3cb6dce3@sk.com>
In-Reply-To: <d38fbfa83d1f421c8a0d201a3cb6dce3@sk.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7HoyNuCF0kCkg5n+JpcOYNt7sw51z4Y/U+Jxw4XRjeQuhobtZVu0hrKOZP2g?=
 =?us-ascii?Q?ycpwnH/NOFx0r/YoK7ZkLBC3xjd9ABXiIksp3U+8fsePHllpq3d0uzFzMm8A?=
 =?us-ascii?Q?4IpgYFco5Lqm18n9s7TSQdWtNH6y4LJRo3EFYlmt/O+P97I936f+yqqvH96k?=
 =?us-ascii?Q?yC4VH3jLyoTH/YirpSQXsVmJI9vAurqZGlosXN4jDEfUwmT37EWUJifX8KOS?=
 =?us-ascii?Q?6owIZNA6utvxwS1vLycouvwU/gLRnV1rzSzL9czQoc4N2AGTMCkA18NtwIER?=
 =?us-ascii?Q?ZFIMibM0aV9lSbJA7s+5Wxha9NdR/rzJiGdf0F5uUOPUnxgy0QJI5ultSmE4?=
 =?us-ascii?Q?FOHP0plCcU+NXN8eYgEncxW0BZuhqXLS57fm5jDojdnl5Ww0J/OekCi4lvT9?=
 =?us-ascii?Q?dJudEitv9H5pAuv0/YbVlnd1QXsTDLrUMjUlvu3fWowLjY6CRPO+iKZDn2cN?=
 =?us-ascii?Q?+bnfaljcTnPRFkj9+NZQ3hWWpoXBVBXPK1vWqDvRwkjrPUPyoK15tHzaomXh?=
 =?us-ascii?Q?r3Azt79iFnBF/v58cy/dG8K+YTtKi21cnWarrdP5rknDQRu3zYiwo59mwQDU?=
 =?us-ascii?Q?ssXzDQfOu9Ig7/q/ovSNdxWUom6h3lEsGEwTMgz9fyXE1ycaLyQEK1QvCehC?=
 =?us-ascii?Q?BdliwS4abJWnX1N98M2jxbvyPmk9OEUgYIBdnlQDmPEoh6hzEFUgqFUCFRdW?=
 =?us-ascii?Q?DDmIoN30r8TrUW2FkX0SFUMDT9I0csgEqsudpDa67zl0Uct1blCJrkMwdGmV?=
 =?us-ascii?Q?Ysq4LGDcupYtTDTkgpyoC9TlZEqfXtoSl38brgCtCpzseV45jgwj1vid4nn6?=
 =?us-ascii?Q?O613sZ7Z/89u0uPwOSubT8rslq+huEoYHuY2Tfks9MBJ7meGu66y+XwjXh/Y?=
 =?us-ascii?Q?gabLd9UynUAIDOeiquYQFqz4+t8QJ7yy4/+zhG9fyVQ3zwhdOivoQPlzi/Jn?=
 =?us-ascii?Q?CmKq/KYbCpDmmzEnTX9wutsPbVi9pqzwv4ySQn7dyd5hSf/2Mcx7+mGgwrb9?=
 =?us-ascii?Q?POkEegvoi6UyPCu46kSi+eLdkb3sNkTLlz1ErXV91XsQ72aKKw7d1d751UvV?=
 =?us-ascii?Q?ssVaqrWWJyefwJP9eCAL/rPB9LTfvqMF0FI4nzkb+TmFxEEQcA5O9NVJeIPQ?=
 =?us-ascii?Q?izuRxuhi5zhI5m7uEx1VAq4VjrWn6XVP0jbL/4ZY2PDSU7fO6gD+Bzszcq1v?=
 =?us-ascii?Q?QhGlnFNw+ot1uBxvVa7X8+ExnQOvWGV+mO39s5Xu1qt6DtsR0gwV7x9PNvkg?=
 =?us-ascii?Q?VKTpUrUT8R3aGKBHC4OeWr3x5iia0GH1kQN0RJM/J6QaV/8m4Hdon0hVa5pC?=
 =?us-ascii?Q?ptU=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: wdc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR04MB6575.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 24715649-cbf6-4557-b2cf-08d92f006c75
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2021 06:48:31.4539
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: z5v2CtjY1L22+tzawKe5RsNTChSCbzgzdIzzuFyev4vx0utl53brKe74UfDIGog0wJV64AbooTtsApWq/Y5bKA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR04MB4154
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > > >+      /*
> > > >+       * If the region state is active, mctx must be allocated.
> > > >+       * In this case, check whether the region is evicted or
> > > >+       * mctx allcation fail.
> > > >+       */
> > > >+      if (unlikely(!srgn->mctx)) {
> > > >+              dev_err(&hpb->sdev_ufs_lu->sdev_dev,
> > > >+                      "no mctx in region %d subregion %d.\n",
> > > >+                      srgn->rgn_idx, srgn->srgn_idx);
> > > >+              return true;
> > > >+      }
> > > >+
> > > >+      if ((srgn_offset + cnt) > bitmap_len)
> > > >+              bit_len =3D bitmap_len - srgn_offset;
> > > >+      else
> > > >+              bit_len =3D cnt;
> > > >+
> > > >+      if (find_next_bit(srgn->mctx->ppn_dirty, bitmap_len,
> > > >+                        srgn_offset) < bit_len + srgn_offset)
> > > >+              return true;
> > > >+
> > >
> > > It seems unnecessary to search through bitmap_len
> > > How about searching by transfer size?
> > >
> > > if (find_next_bit(srgn->mctx->ppn_dirty,
> > >               bit_len + srgn_offset, srgn_offset) < bit_len + srgn_of=
fset)
> > Isn't bit_len should be used for size, and not bit_len + srgn_offset ?
>=20
> then find_next_bit checks from start to bit_len.
> find_next_bit stops checking if start is greater than bit_len.
> it does not check for dirty as transfer_size.
Right. Size (nbits in _find_next_bit) practically means @end - Confusing...
Either way, Is this tad optimization worth another spin in your opinion?

Thanks,
Avri

>=20
> Thanks
> Yohan
>=20
> >
> > Thanks,
> > Avri
> >
> > >
> > > Thanks
> > > Yohan