From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Matthew Wilcox <willy@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
"Mike Rapoport (IBM)" <rppt@kernel.org>,
Deming Wang <wangdeming@inspur.com>,
Ira Weiny <ira.weiny@intel.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Catalin Marinas <catalin.marinas@arm.com>,
Mike Rapoport <rppt@linux.ibm.com>,
Peter Collingbourne <pcc@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Thomas Gleixner <tglx@linutronix.de>,
Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2] Documentation/mm: Add information about kmap_local_folio()
Date: Sun, 02 Jul 2023 15:05:09 +0200 [thread overview]
Message-ID: <2238844.iZASKD2KPV@suse> (raw)
In-Reply-To: <970a881a-cdaf-2568-657a-3b93b0273338@infradead.org>
On domenica 2 luglio 2023 01:59:04 CEST Randy Dunlap wrote:
> On 7/1/23 16:54, Matthew Wilcox wrote:
> > On Sat, Jul 01, 2023 at 08:21:20AM -0700, Randy Dunlap wrote:
> >>> -* kmap_local_page(). This function is used to require short term
> >>> mappings.
> >>> - It can be invoked from any context (including interrupts) but the
> >>> mappings
> >>> - can only be used in the context which acquired them.
> >>> -
> >>> - This function should always be used, whereas kmap_atomic() and kmap()
> >>> have
> >>> +* kmap_local_page(), kmap_local_folio() - These functions are used to
> >>> require
> >>>
> >> acquire?
> >
> > "create" might be better?
>
> Yes, that's good.
Agreed.
However, I can send next version only by week 28th.
Thanks,
Fabio
P.S.: Actually I meant "to request". Unfortunately, "to request" and "to
require" may have the same translation in Italian, my native language.
I preferred to not use "acquire" because it is re-used few lines below. So I
thought that "to request short term mappings" was good (although I wrongly
confused the different meanings between "to require" and "to request").
Matthew's suggestion to use "create" avoids repetition of "acquire(d)".
> >>> + short term mappings. They can be invoked from any context (including
> >>> + interrupts) but the mappings can only be used in the context which
> >>> acquired + them. The only differences between them consist in the first
> >>> taking a pointer + to a struct page and the second taking a pointer to
> >>> struct folio and the byte + offset within the folio which identifies
the
> >>> page.
> >>
> >> --
> >> ~Randy
>
> --
> ~Randy
prev parent reply other threads:[~2023-07-02 13:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-01 14:19 [PATCH v2] Documentation/mm: Add information about kmap_local_folio() Fabio M. De Francesco
2023-07-01 15:21 ` Randy Dunlap
2023-07-01 23:54 ` Matthew Wilcox
2023-07-01 23:59 ` Randy Dunlap
2023-07-02 13:05 ` Fabio M. De Francesco [this message]
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=2238844.iZASKD2KPV@suse \
--to=fmdefrancesco@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=ira.weiny@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pcc@google.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=wangdeming@inspur.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.