These two patches largely revert commits that added function call overhead into slab and page allocation hotpaths and that cannot be currently disabled even though related CONFIG_ options do exist. A much more involved solution that can keep the callsites always existing but hidden behind a static key if unused, is possible [1] and can be pursued by anyone who believes it's necessary. Meanwhile the fact the should_failslab() error injection is already not functional on kernels built with current gcc without anyone noticing [2], and lukewarm response to [1] suggests the need is not there. I believe it will be more fair to have the state after this series as a baseline for possible further optimisation, instead of the unconditional overhead. For example a possible compromise for anyone who's fine with an empty function call overhead but not the full CONFIG_FAILSLAB / CONFIG_FAIL_PAGE_ALLOC overhead is to reuse patch 1 from [1] but insert a static key check only inside should_failslab() and should_fail_alloc_page() before performing the more expensive checks. [1] https://lore.kernel.org/all/20240620-fault-injection-statickeys-v2-0-e23947d3d84b@xxxxxxx/#t [2] https://github.com/bpftrace/bpftrace/issues/3258 Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx> --- Vlastimil Babka (2): mm, slab: put should_failslab() back behind CONFIG_SHOULD_FAILSLAB mm, page_alloc: put should_fail_alloc_page() back behing CONFIG_FAIL_PAGE_ALLOC include/linux/fault-inject.h | 11 ++++------- kernel/bpf/verifier.c | 4 ++++ mm/fail_page_alloc.c | 4 +++- mm/failslab.c | 14 ++++++++------ mm/page_alloc.c | 6 ------ mm/slub.c | 8 -------- 6 files changed, 19 insertions(+), 28 deletions(-) --- base-commit: 256abd8e550ce977b728be79a74e1729438b4948 change-id: 20240711-b4-fault-injection-reverts-e4d099e620f5 Best regards, -- Vlastimil Babka <vbabka@xxxxxxx>
