Ricerche recenti
Opzioni di ricerca
I had a feeling that kernel compilation got slower recently and tried to find the slowest file across randconfig builds. It turned out to be arch/x86/xen/setup.c, which takes 15 seconds to preprocess on a reasonably fast Apple M1 Ultra.
This all comes from one line "extra_pages = min3(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), extra_pages, max_pages - max_pfn);" that expands to 47MB of preprocessor output after commits 80fcac55385c..867046cc70277.
Chatted to @arnd on IRC who suggests he is tied up with stuff to dig into this more so I'll have a wee look :)
EDIT: Think that'll be more likely a report to list + leave others to solve as this seems quite involved and I have a ton of things to do :>)
There are bits of existing code that do this but again, seems super subtle.
Anyway I will leave the details of a solution to others :)
@ljs I think @oblomov is suggesting an intermediate variable in the specific caller, which is a trivial fix and will of course work as it reduces the 47MB to a few KB. The thing we can't easily do is have a temporary variable inside of the min()/max() macros themselves because that prevents them from being used as a C constant expression, e.g. as an array length inside of a type definition.
The problem is we have tons of callers so actually doing that would be a giant pain.
I feel like a way forward may be to have a specific macro for the extremely strict case (type decl) and a looser one for everywhere else that eliminates this.
But question is - how often are we using min()/max() + friends in places like array lengths where we must strictly be const?
@ljs @oblomov Not a lot. In an x86 allmodconfig build I had to fix up these 11 files with a simplified min()/max(). There are probably another dozen for other configs.
drivers/edac/sb_edac.c
drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
drivers/gpu/drm/drm_color_mgmt.c
drivers/input/touchscreen/cyttsp4_core.c
drivers/md/dm-integrity.c
drivers/net/can/usb/etas_es58x/es58x_devlink.c
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
fs/btrfs/tree-checker.c
lib/vsprintf.c
net/ipv4/proc.c
net/ipv6/proc.c
@arnd @ljs yeah, my idea was to do it in the caller, not in the macro. stuff like (types made up. I have no idea what they are):
const int pfn_down_max = PFN_DOWN(MAXMEM);
const int extra_ratio = EXTRA_MEM_RATIO*min(max_pfn, pfn_down_max);
const int leftover = max_pages - max_pfn;
extra_pages = min3(extra_ratio, extra_pages, leftover);
or whatever. Might even increase readability (esp. with comments) in addition to limiting macro expansion blowout.
But in my tests I found that it's not just xen that's the problem, so you'd have to do this everywhere, which isn't really practical.
I mean it's worth whacking this egregious case but it's a band aid, we definitely need a general solution.
I am pretty certain people have also whacked other egregious cases individually too, got major de ja vous over this.
@ljs @arnd ah, that makes perfect sense.
It's a bit frustrating because this would be “trivial” to fix with C++ thanks to templates and constexpr functions (would even work “everywhere” including array indexing).
I remember there used to be a discussion on LKML about having an automatic selector for constant vs non-constant expressions with some fancy tricks, and it was specifically to do this kind of selection, but, did it got anywhere?
But not sure how useful that'd be here, unless you were thinking of something else?
@ljs @arnd I found the discussion I was thinking of. Thread starts here:
https://lkml.org/lkml/2018/3/20/805
and this message specifically is what I was thinking of: