Re: [PATCH 0/7] minmax: reduce compilation time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux