From: Thorsten Blum <thorsten.blum@linux.dev>
To: Lorenzo Stoakes <ljs@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Yury Norov <yury.norov@gmail.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Andy Shevchenko <andriy.shevchenko@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/3] mm: move offset_in_page() to page_helpers.h
Date: Mon, 18 May 2026 15:36:14 +0200 [thread overview]
Message-ID: <agsVzmWMgRZWK2um@linux.dev> (raw)
In-Reply-To: <agsGSp3H0GjEq7Ll@lucifer>
On Mon, May 18, 2026 at 01:33:54PM +0100, Lorenzo Stoakes wrote:
> On Mon, May 18, 2026 at 02:13:54PM +0200, Thorsten Blum wrote:
> > [...]
> > Patch 3/3 is one of many examples that pulls in all of mm.h just for
> > offset_in_page(). lib/string.c from the same thread [1] is another
> > example that would need to include mm.h just for offset_in_page().
>
> And that's a problem why? Compile time? Somehow binary bloat? Conflicts?
> Confusion?
This is more about separation of concerns than about compile time, which
can still matter here, since mm.h is large, pulls in many other headers,
and any changes to those can cause unrelated files to be recompiled.
I don't mind including mm.h where the code already depends on MM
interfaces, but offset_in_page() itself is a small page-arithmetic
helper. Having it buried 3000+ lines into mm.h also makes it less
discoverable, which may be one reason it's not used more often.
> > Many other files (hundreds) don't use offset_in_page(), but open-code it
> > in many different ways instead:
> >
> > (unsigned long)p & ~PAGE_MASK
> > (unsigned long)p & (PAGE_SIZE - 1)
> > (long)p & (PAGE_SIZE - 1)
> > ...
> >
> > I can't tell whether they didn't know about offset_in_page(), or
> > deliberately chose not to include mm.h.
>
> OK but this series doesn't address any of that? It just adds a new header, a
> questionable macro and uses it in one place? So those justifications are rather
> moot here.
My intent was to make the helper available from a smaller header first,
and to use patch 3/3 as a concrete example where including all of mm.h
is unnecessary. Other call sites can then be converted incrementally
over time, rather than sending a tree-wide conversion in the same
series.
Thanks,
Thorsten
next prev parent reply other threads:[~2026-05-18 13:36 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-17 12:34 [PATCH 1/3] mm: move offset_in_page() to page_helpers.h Thorsten Blum
2026-05-17 12:34 ` [PATCH 2/3] mm: add bytes_to_page_end() helper Thorsten Blum
2026-05-17 15:28 ` Yury Norov
2026-05-18 6:48 ` Andy Shevchenko
2026-05-18 10:23 ` Lorenzo Stoakes
2026-05-18 11:33 ` William Kucharski
2026-05-18 11:53 ` William Kucharski
2026-05-18 9:09 ` David Laight
2026-05-18 10:24 ` Lorenzo Stoakes
2026-05-18 13:06 ` David Hildenbrand (Arm)
2026-05-18 13:15 ` Lorenzo Stoakes
2026-05-18 13:24 ` David Hildenbrand (Arm)
2026-05-18 13:38 ` Lorenzo Stoakes
2026-05-18 14:29 ` Thomas Weißschuh
2026-05-18 14:41 ` David Hildenbrand (Arm)
2026-05-18 14:52 ` Thomas Weißschuh
2026-05-18 15:32 ` David Hildenbrand (Arm)
2026-05-18 6:49 ` Andy Shevchenko
2026-05-18 10:24 ` Lorenzo Stoakes
2026-05-17 12:34 ` [PATCH 3/3] lib/bitmap: use " Thorsten Blum
2026-05-18 10:33 ` Lorenzo Stoakes
2026-05-18 15:29 ` Yury Norov
2026-05-18 6:51 ` [PATCH 1/3] mm: move offset_in_page() to page_helpers.h Andy Shevchenko
2026-05-18 10:02 ` Lorenzo Stoakes
2026-05-18 12:13 ` Thorsten Blum
2026-05-18 12:33 ` Lorenzo Stoakes
2026-05-18 13:36 ` Thorsten Blum [this message]
2026-05-18 14:03 ` Lorenzo Stoakes
2026-05-18 12:58 ` David Hildenbrand (Arm)
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=agsVzmWMgRZWK2um@linux.dev \
--to=thorsten.blum@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@intel.com \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=yury.norov@gmail.com \
/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.