Message ID | 063721a02d5e226d1e9e9782f76ce94c16d73e93.1688073459.git.drv@mailo.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp9944537vqr; Thu, 29 Jun 2023 15:12:26 -0700 (PDT) X-Google-Smtp-Source: APBJJlHvm2NjCAqUc9LewzPpXkve3l2mPO5l5GpabjMqvjzolup2drNM6KPhkE2mY0cfDGRV5OhS X-Received: by 2002:a17:902:7611:b0:1b8:2ba0:c9a8 with SMTP id k17-20020a170902761100b001b82ba0c9a8mr529128pll.2.1688076745726; Thu, 29 Jun 2023 15:12:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688076745; cv=none; d=google.com; s=arc-20160816; b=k5/KVN0uCNPFPaVNAdf00FJg5dNPovbBGtlhobKas7j1jzUJSL0xEUo+PnPThj+8SI yg39FIGAnCb2dWqZXjix3YPZyRCMHdIDOtIqj2WKGdP9p+Z5FfcZMa/UMyOUtfv0TjuM 0Qn6UookgvVBUGDobx/vMGnOWG6DE1yFCWSGIl7k+jXqiu0yF1fNeJYz3cNxwpHQ75zD GnAO94mqCPamy9N91q4MD1sIoUnyePjl2oDmu3u48KGhnYRFZf8Nz3bUklvPkmC17IWU LwsZoVak+7IH+mHxfM0e0GcvNRPViGWySBYHe5r3PANHOAZjk9pqApy1VptRfacJpdYW tJgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=JLjCoTRJbuen8JADQEFzaEd11cEiRRgjR5JMnKL0+KE=; fh=2/OepbD16sII06AHmQTJgD7xcw2OMNoUEY9t7KuTeGw=; b=Ozp30ivtmCkqAhPJvzkG2NnB6Z9wwQlDYA1aONh5BhdDm2YdXELXAzPk3qVVJHq4wx WQZAxPwAOH7cNs97zooDQZXQr98lNTjJLrWzvGySr/CEk6gCD1tavIyXiw9A4PnC0dF0 +YmNrJVGkUVuvjd+KWUm5+I3jktxmitfCTJerORDAU+u/d5KDvITY7ibK5sEMMUcM9Ir wpBeD3R6lbjMbenI53qvO42ltXnIcZDnZu92xlKaV30cnSeEh6+H4nNUayBGc8otbaY3 QmGLgb6vMDenbsgdUJ+uzOV9Yr8YuOyJ5HqlA2k1uhgT46dlVS4T353LZHbhpv+ZH2Bw Etxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=RKNVi0JK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k9-20020a170902c40900b001afd000029bsi11349078plk.581.2023.06.29.15.12.12; Thu, 29 Jun 2023 15:12:25 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=RKNVi0JK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231839AbjF2VvA (ORCPT <rfc822;ivan.orlov0322@gmail.com> + 99 others); Thu, 29 Jun 2023 17:51:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229742AbjF2Vu6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 29 Jun 2023 17:50:58 -0400 Received: from msg-4.mailo.com (msg-4.mailo.com [213.182.54.15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F2AE30C5 for <linux-kernel@vger.kernel.org>; Thu, 29 Jun 2023 14:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1688075453; bh=oLlIroBMRDkkKoSKm/jnig64fpkTQsUV8Vs7jXlV6S4=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To; b=RKNVi0JK9yb6y9ikoObZVDdxHNI2S5uutZblCHSGincf4Psj2Ag97vTYB5aVbRMcc UrrHBFMqhOnr34uVCquYANjyCyOuq2cOBJitjHzlTIduyd8E1sd62ksQ/gDaTJBvC/ PNM1qd/6Uo+B49nl1VgykaL04dtw4uwhJhusDBCY= Received: by b221-6.in.mailobj.net [192.168.90.26] with ESMTP via ip-20.mailobj.net [213.182.54.20] Thu, 29 Jun 2023 23:50:53 +0200 (CEST) X-EA-Auth: ZFhqXnP7AsOSoIr/Ef0GqN9/yMiSC8/ZRNPogc47fkLBPnGNkvMpik0u2PJ2NVJJPLCdjVVzGTceRqslXnom3aOt+GdSlj3f Date: Fri, 30 Jun 2023 03:20:43 +0530 From: Deepak R Varma <drv@mailo.com> To: Bob Peterson <rpeterso@redhat.com>, Andreas Gruenbacher <agruenba@redhat.com>, cluster-devel@redhat.com, linux-kernel@vger.kernel.org Cc: Ira Weiny <ira.weiny@intel.com>, "Fabio M. De Francesco" <fmdefrancesco@gmail.com>, Sumitra Sharma <sumitraartsy@gmail.com>, Deepak R Varma <drv@mailo.com> Subject: [PATCH v3 3/6] gfs2: Replace kmap() by kmap_local_page() in gfs2_unstuffer_page Message-ID: <063721a02d5e226d1e9e9782f76ce94c16d73e93.1688073459.git.drv@mailo.com> References: <cover.1688073459.git.drv@mailo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <cover.1688073459.git.drv@mailo.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770076761198564208?= X-GMAIL-MSGID: =?utf-8?q?1770076761198564208?= |
Series |
gfs2: kmap{_atomic} conversion to kmap_local_{page/folio}
|
|
Commit Message
Deepak R Varma
June 29, 2023, 9:50 p.m. UTC
The use of kmap() is being deprecated in favor of kmap_local_page().
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’s pool wraps and it might block when the mapping space is fully
utilized until a slot becomes available.
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.
Therefore, replace kmap() with kmap_local_page() in gfs2_unstuffer_page().
Suggested-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Signed-off-by: Deepak R Varma <drv@mailo.com>
---
Changes in v3:
- Patch included in the patch series
Changes in v2:
- None
fs/gfs2/bmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On giovedì 29 giugno 2023 23:50:43 CEST Deepak R Varma wrote: > The use of kmap() is being deprecated in favor of kmap_local_page(). > > 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’s pool wraps and it might block when the mapping space is fully > utilized until a slot becomes available. > > 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. > > Therefore, replace kmap() with kmap_local_page() in gfs2_unstuffer_page(). > > 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 think that you are not required by any stated formal rule, however it would be much appreciated (by me, at least :-)). > Changes in v3: > - Patch included in the patch series > > Changes in v2: > - None > > > fs/gfs2/bmap.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > 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 = &ip->i_inode; > > if (!PageUptodate(page)) { > - void *kaddr = kmap(page); > + void *kaddr = kmap_local_page(page); > u64 dsize = i_size_read(inode); As a general rule, we should take the mappings the shorter time it is possible (to avoid to disable migration for too long). I'm not sure why the "dsize" assignment is made between mapping and un-mapping. Can you please explain why? Thanks, Fabio > memcpy(kaddr, dibh->b_data + sizeof(struct gfs2_dinode), dsize); > memset(kaddr + dsize, 0, PAGE_SIZE - dsize); > - kunmap(page); > + kunmap_local(kaddr); > > SetPageUptodate(page); > } > -- > 2.34.1
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 = &ip->i_inode; if (!PageUptodate(page)) { - void *kaddr = kmap(page); + void *kaddr = kmap_local_page(page); u64 dsize = i_size_read(inode); memcpy(kaddr, dibh->b_data + sizeof(struct gfs2_dinode), dsize); memset(kaddr + dsize, 0, PAGE_SIZE - dsize); - kunmap(page); + kunmap_local(kaddr); SetPageUptodate(page); }