From: Matthew Wilcox <willy@infradead.org>
To: "Fabio M. De Francesco" <fabio.maria.de.francesco@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
"Mike Rapoport (IBM)" <rppt@kernel.org>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Kim Phillips <kim.phillips@amd.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation/mm: Describe folios in physical_memory.rst
Date: Fri, 15 Dec 2023 14:36:21 +0000 [thread overview]
Message-ID: <ZXxkZcq4rzlzsiZh@casper.infradead.org> (raw)
In-Reply-To: <20231215120022.2010667-1-fabio.maria.de.francesco@linux.intel.com>
On Fri, Dec 15, 2023 at 01:00:12PM +0100, Fabio M. De Francesco wrote:
> +A folio is a physically, virtually and logically contiguous set of bytes.
> +It is a power-of-two in size, and it is aligned to that same power-of-two.
> +It is at least as large as %PAGE_SIZE. If it is in the page cache, it is
> +at a file offset which is a multiple of that power-of-two. It may be
> +mapped into userspace at an address which is at an arbitrary page offset,
> +but its kernel virtual address is aligned to its size.
This text is verbatim from include/linux/mm_types.h. It seems sad
to have kernel-doc and then replicate it in an rst file.
> +As Matthew Wilcox explains in his introduction to folios, the need for
oof, no, don't mention my name.
> +`struct folio` arises mostly to address issues with the use of compound
> +pages. It is often unclear whether a function operates on an individual
> +page, or an entire compound page.
> +
> +"A function which has a `struct page` pointer argument might be
> +expecting a head or base page and will BUG if given a tail page. It might
> +work with any kind of page and operate on %PAGE_SIZE bytes. It might work
> +with any kind of page and operate on page_size() bytes if given a head
> +page but %PAGE_SIZE bytes if given a base or tail page. It might operate
> +on page_size() bytes if passed a head or tail page. We have examples of
> +all of these today.".
> +
> +A pointer to folio points to a page that is never a tail page. It
> +represents an entire compound page. Therefore, there is no need to call
> +compound_head() to get a pointer to the head. Folios has eliminted the
> +need to unnecessary calls and has avoided bugs related to the misuse of
> +pages passed to functions. Furthermore, the inline compound_head() makes
> +the kernel bigger and slows things down.
> +
> +The folio APIs are described in the "Memory Management APIs" document.
This was exactly the kind of documentation I was hoping you wouldn't
write ;-( It's documentation that makes sense today, but won't in five
years time.
We want to say something like,
A folio represents a single memory allocation. It may be composed of
several pages ...
next prev parent reply other threads:[~2023-12-15 14:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 12:00 [PATCH] Documentation/mm: Describe folios in physical_memory.rst Fabio M. De Francesco
2023-12-15 14:36 ` Matthew Wilcox [this message]
2023-12-15 16:29 ` Fabio M. De Francesco
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=ZXxkZcq4rzlzsiZh@casper.infradead.org \
--to=willy@infradead.org \
--cc=bagasdotme@gmail.com \
--cc=corbet@lwn.net \
--cc=fabio.maria.de.francesco@linux.intel.com \
--cc=kim.phillips@amd.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lstoakes@gmail.com \
--cc=lukas.bulwahn@gmail.com \
--cc=rppt@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox