Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Bob Peterson <rpeterso@redhat.com>,
        Andreas Gruenbacher <agruenba@redhat.com>,
        cluster-devel@redhat.com, linux-kernel@vger.kernel.org,
        Deepak R Varma <drv@mailo.com>
Cc:     Ira Weiny <ira.weiny@intel.com>,
        Sumitra Sharma <sumitraartsy@gmail.com>,
        Deepak R Varma <drv@mailo.com>
Subject: Re: [PATCH v3 3/6] gfs2: Replace kmap() by kmap_local_page() in
 gfs2_unstuffer_page
Date:   Sat, 01 Jul 2023 15:01:02 +0200
Message-ID: <2946216.VdNmn5OnKV@suse>
In-Reply-To: <063721a02d5e226d1e9e9782f76ce94c16d73e93.1688073459.git.drv@mailo.com>
References: <cover.1688073459.git.drv@mailo.com>
 <063721a02d5e226d1e9e9782f76ce94c16d73e93.1688073459.git.drv@mailo.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Precedence: bulk

On gioved=C3=AC 29 giugno 2023 23:50:43 CEST Deepak R Varma wrote:
> The use of kmap() is being deprecated in favor of kmap_local_page().
>=20
> There are two main problems with kmap(): (1) It comes with an overhead as
> the mapping space is restricted and protected by a global lock for
> synchronization and (2) it also requires global TLB invalidation when the
> kmap=E2=80=99s pool wraps and it might block when the mapping space is fu=
lly
> utilized until a slot becomes available.
>=20
> With kmap_local_page() the mappings are per thread, CPU local, can take
> page faults, and can be called from any context (including interrupts).
> It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore,
> the tasks can be preempted and, when they are scheduled to run again, the
> kernel virtual addresses are restored and still valid.
>=20
> Therefore, replace kmap() with kmap_local_page() in gfs2_unstuffer_page().
>=20
> Suggested-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> Signed-off-by: Deepak R Varma <drv@mailo.com>
> ---

Deepak,

Would you please cite the author of this boiler-plate commit message? I thi=
nk=20
that you are not required by any stated formal rule, however it would be mu=
ch=20
appreciated (by me, at least :-)).

> Changes in v3:
>    - Patch included in the patch series
>=20
> Changes in v2:
>    - None
>=20
>=20
>  fs/gfs2/bmap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>=20
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index 8d611fbcf0bd..6b850e2ba5c8 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -58,12 +58,12 @@ static int gfs2_unstuffer_page(struct gfs2_inode *ip,
> struct buffer_head *dibh, struct inode *inode =3D &ip->i_inode;
>=20
>  	if (!PageUptodate(page)) {
> -		void *kaddr =3D kmap(page);
> +		void *kaddr =3D kmap_local_page(page);
>  		u64 dsize =3D i_size_read(inode);

As a general rule, we should take the mappings the shorter time it is possi=
ble=20
(to avoid to disable migration for too long). I'm not sure why the "dsize"=
=20
assignment is made between mapping and un-mapping. Can you please explain w=
hy?

Thanks,

=46abio

>  		memcpy(kaddr, dibh->b_data + sizeof(struct gfs2_dinode),=20
dsize);
>  		memset(kaddr + dsize, 0, PAGE_SIZE - dsize);
> -		kunmap(page);
> +		kunmap_local(kaddr);
>=20
>  		SetPageUptodate(page);
>  	}
> --
> 2.34.1