Re: [PATCH 0/7] minmax: reduce compilation time
From: Linus Torvalds
Date: Sat Jul 27 2024 - 14:17:05 EST
On Sat, 27 Jul 2024 at 10:34, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> In the specific case of PageLocked, that can hopefully go away fairly
> soon. We only have 24 instances left in tree and five of those are
> comments/docs. The ones in fs (btrfs, crypto, f2fs, ocfs2 and pipe)
> should be converted to folio soon.
So unlike the min/max mess, at least in this case there's some
_reason_ for the long lines (ie it's not some long line because of
just mindless expansion, it's a long line because it defines several
helper functions intentionally in one go).
End result: I don't think these are really in the same class as some
of the min/max expansion issues, but:
> But I have been wondering whether the way we define all the functions
> around page/folio flags is sensible. Every file which includes
> page-flags.h (... which is most of them ...) regenerates the macros.
> You can't grep for the definition of folio_test_locked(). There's
> nowhere to put kernel-doc for folio_test_locked().
Right, these things do have their own issues, and the different flag
handling helper functions _used_ to be simpler than they are now. It
is indeed a pain to grep for, for example, and yes, it gets included
for a lot of people who simply don't need it or want it.
I'm not convinced having it in a generated file would help the
greppability - I certainly don't use "grep -R" any more, I use "git
grep", which by definition will never see any generated files any more
than it sees pre-processor output.
But whether those functions should be in one core header file at all,
that's clearly questionable. I wonder how inlined they need to be
either, outside of the trivial cases.
(And when I say "those functions", I don't mean just the pageflag
ones. The folio ones largely have all the same issues - except the
"page" ones have a *TON* of debugging code in them, so they expand to
be much bigger)
Side note: one very simple thing to do might be to short-circuit the
"constant bit number" test in the bitops that the PG_##flags cases
use. That's a lot of noise to select between "simple constant bit
number" and "generic variable one" when we know they are all constant.
Linus