Message ID | 20231215084417.2002370-1-fabio.maria.de.francesco@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-633-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp9128492dys; Fri, 15 Dec 2023 00:45:03 -0800 (PST) X-Google-Smtp-Source: AGHT+IHjIYrqh96srm8BO94y1hKamOAJJ3BXqu1dR5SAQIZmjbSq/qH55J4UJbKZ85tDTpT2VczC X-Received: by 2002:a05:6358:c613:b0:170:17eb:1eb with SMTP id fd19-20020a056358c61300b0017017eb01ebmr5952034rwb.46.1702629903635; Fri, 15 Dec 2023 00:45:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702629903; cv=none; d=google.com; s=arc-20160816; b=xtHNr62ITuD4+8puFxO8xMpr8dCcqcC6y6jcV8P7VmM44I2dVDcO1mXT89bautZb7k FyyMM/xUwxI7q/w/FFO1NAx4p2RcLaARWCJOEzK5FfJ6JwjHqtYB5BkkPILq9wDLH6wj pXnXwUHMguBxaIXd9QzyCycyJhTWd/YyTPYRYUGwlIX+R/GeihhMcs7gaTl9HymMHiHg WKG5d412hqcI7g2fJLt2tsCxT2HUBE+DqB99ITMa46HyBEQK9q2yYVtDmwbaZaga7M86 FTtA5kmxKRw4wJn3WeMXU34deQP+D3Acd2iKXfR0ceFFFuqXVD0zom77Kw8WgfaqNVAA hCzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=JfgwSx9MLlfnDdw7inRAgD1RuEgYGXNHCOCtslBaJpc=; fh=XH3pxpKr7AUB4GM0Y3GdAQEzWmNMu4SdIEH1hms+9D0=; b=FdI+vqCyWQBYdmoLvmtlcxKOPeHhfl3iP9H7P0vSp+EFz0/aIh4586pTtk7Q9Gb2Nr +x0MHCq6S20RXjLLhO4sl5rFDfcyTmqnEYaOp/ghm3KJ23i3TOMXwXapGj3BjfpWWaCA nsNL4wTX/ZarluHm26gRVjqFKny8GoG2KE8g9pFGGFv60hOMplKqYOWsESUzppkKq/jh MEFe2sASAlY2QahhQPoN/sw24gSCjv5/fPLSpZcX8gNBkgvB7Zu3S6dcnNviFuTvEnoO xYJDVO31Ql51T+NCGzoybeKF4szUJ/Xm9PAdpKh3+rDexFY5yJORZs9nbx2mmW4j13ki TjZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=g8pPYagq; spf=pass (google.com: domain of linux-kernel+bounces-633-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-633-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id f20-20020a056a00239400b006d0c02f0070si4760912pfc.353.2023.12.15.00.45.03 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 00:45:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-633-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=g8pPYagq; spf=pass (google.com: domain of linux-kernel+bounces-633-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-633-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 6C216B22412 for <ouuuleilei@gmail.com>; Fri, 15 Dec 2023 08:44:46 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1DE17171C1; Fri, 15 Dec 2023 08:44:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="g8pPYagq" X-Original-To: linux-kernel@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25D77D27A for <linux-kernel@vger.kernel.org>; Fri, 15 Dec 2023 08:44:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1702629866; x=1734165866; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=pN6Za6QS6gH0Sone+vJpcFhDUA34F+4C+dHQJlQSAlc=; b=g8pPYagqW54B+3rP7kbG30x2G57uGPTWvP0RzFRbhfynpsszj1+h/iOP HokDceLy04mFAzVFdrJ8qzp3T3evr7YoK4lKzGusm9LSby/itMMn4+iDy 7OA5VIuFnIl4NFjb4p7TigvqCqZZlHLSwopGz84QKeuMcBKHwqHt1Ebmi eJc/MplvZrzjg/0L+jm7oTGeclutFfT3itcPElAqDoo5RJp29PEhEYzXx /+r95NgN6GCn9Eg1BF5xiMizvLRQpuzFBRCqZJEUZ9npXtxSP7uSPE6RV WOAmr76L88arzBzqQPUEDu6NPLe0TZqwiNY8yi9s5xy0ffD0ePUv37enb w==; X-IronPort-AV: E=McAfee;i="6600,9927,10924"; a="426381356" X-IronPort-AV: E=Sophos;i="6.04,278,1695711600"; d="scan'208";a="426381356" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2023 00:44:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10924"; a="808895806" X-IronPort-AV: E=Sophos;i="6.04,278,1695711600"; d="scan'208";a="808895806" Received: from fdefranc-mobl3.ger.corp.intel.com (HELO fdefranc-mobl3.Hitronhub.home) ([10.213.25.64]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2023 00:44:22 -0800 From: "Fabio M. De Francesco" <fabio.maria.de.francesco@linux.intel.com> To: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: "Fabio M. De Francesco" <fabio.maria.de.francesco@linux.intel.com>, Ira Weiny <ira.weiny@intel.com> Subject: [PATCH] mm/memory: Replace kmap() with kmap_local_page() Date: Fri, 15 Dec 2023 09:43:40 +0100 Message-ID: <20231215084417.2002370-1-fabio.maria.de.francesco@linux.intel.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785244152126593850 X-GMAIL-MSGID: 1785336853620017843 |
Series |
mm/memory: Replace kmap() with kmap_local_page()
|
|
Commit Message
Fabio M. De Francesco
Dec. 15, 2023, 8:43 a.m. UTC
kmap() has been deprecated in favor of kmap_local_page().
Therefore, replace kmap() with kmap_local_page() in mm/memory.c.
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. The tasks can
be preempted and, when they are scheduled to run again, the kernel
virtual addresses are restored and still valid.
Obviously, thread locality implies that the kernel virtual addresses
returned by kmap_local_page() are only valid in the context of the
callers (i.e., they cannot be handed to other threads).
The use of kmap_local_page() in mm/memory.c does not break the
above-mentioned assumption, so it is allowed and preferred.
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Fabio M. De Francesco <fabio.maria.de.francesco@linux.intel.com>
---
mm/memory.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Comments
Fabio M. De Francesco wrote: [snip] > > Cc: Ira Weiny <ira.weiny@intel.com> > Signed-off-by: Fabio M. De Francesco <fabio.maria.de.francesco@linux.intel.com> > --- > mm/memory.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 7d9f6b685032..88377a107fbe 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -5852,7 +5852,7 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr, > if (bytes > PAGE_SIZE-offset) > bytes = PAGE_SIZE-offset; > > - maddr = kmap(page); > + maddr = kmap_local_page(page); > if (write) { > copy_to_user_page(vma, page, addr, > maddr + offset, buf, bytes); > @@ -5861,8 +5861,7 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr, > copy_from_user_page(vma, page, addr, > buf, maddr + offset, bytes); > } > - kunmap(page); > - put_page(page); > + unmap_and_put_page(page, maddr); Does this really have the same functionality? Ira
On Monday, 18 December 2023 04:34:13 CET Ira Weiny wrote: > Fabio M. De Francesco wrote: > > [snip] > > > Cc: Ira Weiny <ira.weiny@intel.com> > > Signed-off-by: Fabio M. De Francesco > > <fabio.maria.de.francesco@linux.intel.com> --- > > > > mm/memory.c | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index 7d9f6b685032..88377a107fbe 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -5852,7 +5852,7 @@ static int __access_remote_vm(struct mm_struct *mm, > > unsigned long addr,> > > if (bytes > PAGE_SIZE-offset) > > > > bytes = PAGE_SIZE-offset; > > > > - maddr = kmap(page); > > + maddr = kmap_local_page(page); > > > > if (write) { > > > > copy_to_user_page(vma, page, addr, > > > > maddr + offset, buf, bytes); > > > > @@ -5861,8 +5861,7 @@ static int __access_remote_vm(struct mm_struct *mm, > > unsigned long addr,> > > copy_from_user_page(vma, page, addr, > > > > buf, maddr + offset, bytes); > > > > } > > > > - kunmap(page); > > - put_page(page); > > + unmap_and_put_page(page, maddr); > > Does this really have the same functionality? > > Ira Do you have any specific reasons to say that? The unmap_and_put_page() helper was created by Al Viro (it initially was put_and_unmap_page() and I sent a patch to rename it to the current name). He noticed that we have lots of kunmap_local() followed by put_page(). The current implementation has then been changed (Matthew did it, if I remember correctly). My understanding of the current implementation is that unmap_and_put_page() calls folio_release_kmap(), taking as arguments the folio which the page belongs to and the kernel virtual address returned by kmap_local_page(). folio_release_kmap() calls kunmap_local() and then folio_put(). The last is called on the folio obtained by the unmap_and_put_page() wrapper and, if I'm not wrong, it releases refcounts on folios like put_page() does on pages. Am I missing something? For further reference, please take a look at the following path from Al Viro that is modelled after my conversions in fs/sysv: https://lore.kernel.org/all/ 20231213000849.2748576-4-viro@zeniv.linux.org.uk/ Thanks, Fabio
Fabio M. De Francesco wrote: > On Monday, 18 December 2023 04:34:13 CET Ira Weiny wrote: > > Fabio M. De Francesco wrote: > > > > [snip] > > > > > Cc: Ira Weiny <ira.weiny@intel.com> > > > Signed-off-by: Fabio M. De Francesco > > > <fabio.maria.de.francesco@linux.intel.com> --- > > > > > > mm/memory.c | 5 ++--- > > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > > > diff --git a/mm/memory.c b/mm/memory.c > > > index 7d9f6b685032..88377a107fbe 100644 > > > --- a/mm/memory.c > > > +++ b/mm/memory.c > > > @@ -5852,7 +5852,7 @@ static int __access_remote_vm(struct mm_struct *mm, > > > unsigned long addr,> > > > if (bytes > PAGE_SIZE-offset) > > > > > > bytes = PAGE_SIZE-offset; > > > > > > - maddr = kmap(page); > > > + maddr = kmap_local_page(page); > > > > > > if (write) { > > > > > > copy_to_user_page(vma, page, addr, > > > > > > maddr + offset, buf, > bytes); > > > > > > @@ -5861,8 +5861,7 @@ static int __access_remote_vm(struct mm_struct *mm, > > > unsigned long addr,> > > > copy_from_user_page(vma, page, addr, > > > > > > buf, maddr + offset, > bytes); > > > > > > } > > > > > > - kunmap(page); > > > - put_page(page); > > > + unmap_and_put_page(page, maddr); > > > > Does this really have the same functionality? > > > > Ira > > Do you have any specific reasons to say that? > > The unmap_and_put_page() helper was created by Al Viro (it initially was > put_and_unmap_page() and I sent a patch to rename it to the current name). He > noticed that we have lots of kunmap_local() followed by put_page(). > > The current implementation has then been changed (Matthew did it, if I > remember correctly). > > My understanding of the current implementation is that unmap_and_put_page() > calls folio_release_kmap(), taking as arguments the folio which the page > belongs to and the kernel virtual address returned by kmap_local_page(). > > folio_release_kmap() calls kunmap_local() and then folio_put(). The last is > called on the folio obtained by the unmap_and_put_page() wrapper and, if I'm > not wrong, it releases refcounts on folios like put_page() does on pages. This is where my consternation came from. I saw the folio_put() and did not realize that get_page() now calls folio_get(). > > Am I missing something? Nope, I just did not have time to trace code yesterday. Reviewed-by: Ira Weiny <ira.weiny@intel.com>
On Wed, Dec 20, 2023 at 11:53:34AM -0800, Ira Weiny wrote: > > My understanding of the current implementation is that unmap_and_put_page() > > calls folio_release_kmap(), taking as arguments the folio which the page > > belongs to and the kernel virtual address returned by kmap_local_page(). > > > > folio_release_kmap() calls kunmap_local() and then folio_put(). The last is > > called on the folio obtained by the unmap_and_put_page() wrapper and, if I'm > > not wrong, it releases refcounts on folios like put_page() does on pages. > > This is where my consternation came from. I saw the folio_put() and did > not realize that get_page() now calls folio_get(). That's not new. See 86d234cb0499 which changed get_page() to call folio_get(), but notice that it's doing the _exact same thing_ that get_page() used to do. And it's behaved this way since ddc58f27f9ee in 2016.
diff --git a/mm/memory.c b/mm/memory.c index 7d9f6b685032..88377a107fbe 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5852,7 +5852,7 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr, if (bytes > PAGE_SIZE-offset) bytes = PAGE_SIZE-offset; - maddr = kmap(page); + maddr = kmap_local_page(page); if (write) { copy_to_user_page(vma, page, addr, maddr + offset, buf, bytes); @@ -5861,8 +5861,7 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr, copy_from_user_page(vma, page, addr, buf, maddr + offset, bytes); } - kunmap(page); - put_page(page); + unmap_and_put_page(page, maddr); } len -= bytes; buf += bytes;