From: Vlastimil Babka <vbabka@suse.cz>
To: David Rientjes <rientjes@google.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>,
Christoph Lameter <cl@linux.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Masami Hiramatsu <mhiramat@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/4] static key support for error injection functions
Date: Sun, 2 Jun 2024 23:08:10 +0200 [thread overview]
Message-ID: <f21161e9-1da6-4015-907d-e419ec5056da@suse.cz> (raw)
In-Reply-To: <71ebaa45-dbd0-b39d-4b33-88da3f497297@google.com>
On 6/2/24 10:47 PM, David Rientjes wrote:
> On Fri, 31 May 2024, Vlastimil Babka wrote:
>
>> Patches 3 and 4 implement the static keys for the two mm fault injection
>> sites in slab and page allocators. For a quick demonstration I've run a
>> VM and the simple test from [1] that stresses the slab allocator and got
>> this time before the series:
>>
>> real 0m8.349s
>> user 0m0.694s
>> sys 0m7.648s
>>
>> with perf showing
>>
>> 0.61% nonexistent [kernel.kallsyms] [k] should_failslab.constprop.0
>> 0.00% nonexistent [kernel.kallsyms] [k] should_fail_alloc_page ▒
>>
>> And after the series
>>
>> real 0m7.924s
>> user 0m0.727s
>> sys 0m7.191s
>>
>> and the functions gone from perf report.
>>
>
> Impressive results that will no doubt be a win for kernels that enable
> these options.
Oh, I should have been more clear about it. This was done with both of these
options disabled. It's measuring just removing the overhead of calling the
empty noninline function, otherwise the difference would be larger. CPU
mitigations (defaults) were enabled though, which affects the cost of
function calls (this was in KVM guest on Ryzen 2700).
> Both CONFIG_FAILSLAB and CONFIG_FAIL_PAGE_ALLOC go out of their way to
> have no overhead, both in performance and kernel text overhead, when the
> .config options are disabled.
Except the unavoidable function call overhead since commits 4f6923fbb352 and
af3b854492f3.
> Do we have any insight into the distros or users that enable either of
> these options and are expecting optimal performance? I would have assumed
> that while CONFIG_FAULT_INJECTION may be enabled that any users who would
> care deeply about this would have disabled both of these debug options.
Eliminating the empty function call overhead, which is currently not
possible to configure out in any way, was my primary goal. For our distro we
disable the options and they are enabled only in a debug kernel option. So
the additional benefit of the static key is we could enable them with no
cost, and have them available for when needed, without the need to change
kernel. This is great for debugging functionality in general
(debug_pagealloc, page_owner), maybe this would be less likely to be useful,
but one never knows.
>> There might be other such fault injection callsites in hotpaths of other
>> subsystems but I didn't search for them at this point.
>>
>> [1] https://lore.kernel.org/all/6d5bb852-8703-4abf-a52b-90816bccbd7f@suse.cz/
>> [2] https://lore.kernel.org/all/3j5d3p22ssv7xoaghzraa7crcfih3h2qqjlhmjppbp6f42pg2t@kg7qoicog5ye/
>>
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>> ---
>> Vlastimil Babka (4):
>> fault-inject: add support for static keys around fault injection sites
>> error-injection: support static keys around injectable functions
>> mm, slab: add static key for should_failslab()
>> mm, page_alloc: add static key for should_fail_alloc_page()
>>
>> include/asm-generic/error-injection.h | 13 ++++++++++-
>> include/asm-generic/vmlinux.lds.h | 2 +-
>> include/linux/error-injection.h | 9 +++++---
>> include/linux/fault-inject.h | 7 +++++-
>> kernel/fail_function.c | 22 +++++++++++++++---
>> lib/error-inject.c | 6 ++++-
>> lib/fault-inject.c | 43 ++++++++++++++++++++++++++++++++++-
>> mm/fail_page_alloc.c | 3 ++-
>> mm/failslab.c | 2 +-
>> mm/internal.h | 2 ++
>> mm/page_alloc.c | 11 ++++++---
>> mm/slab.h | 3 +++
>> mm/slub.c | 10 +++++---
>> 13 files changed, 114 insertions(+), 19 deletions(-)
>> ---
>> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
>> change-id: 20240530-fault-injection-statickeys-66b7222e91b7
>>
>> Best regards,
>> --
>> Vlastimil Babka <vbabka@suse.cz>
>>
>>
prev parent reply other threads:[~2024-06-02 21:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 9:33 Vlastimil Babka
2024-05-31 9:33 ` [PATCH RFC 1/4] fault-inject: add support for static keys around fault injection sites Vlastimil Babka
2024-05-31 9:33 ` [PATCH RFC 2/4] error-injection: support static keys around injectable functions Vlastimil Babka
2024-06-02 14:19 ` Masami Hiramatsu
2024-05-31 9:33 ` [PATCH RFC 3/4] mm, slab: add static key for should_failslab() Vlastimil Babka
2024-05-31 16:43 ` Alexei Starovoitov
2024-05-31 17:17 ` Yosry Ahmed
2024-06-01 20:57 ` Vlastimil Babka
2024-06-02 19:12 ` Alexei Starovoitov
2024-05-31 23:44 ` Roman Gushchin
2024-05-31 9:33 ` [PATCH RFC 4/4] mm, page_alloc: add static key for should_fail_alloc_page() Vlastimil Babka
2024-05-31 23:50 ` Roman Gushchin
2024-05-31 15:31 ` [PATCH RFC 0/4] static key support for error injection functions Mark Rutland
2024-06-01 20:48 ` Vlastimil Babka
2024-05-31 23:39 ` Roman Gushchin
2024-06-01 20:53 ` Vlastimil Babka
2024-06-02 11:36 ` Wei Yang
2024-06-02 20:47 ` David Rientjes
2024-06-02 21:08 ` Vlastimil Babka [this message]
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=f21161e9-1da6-4015-907d-e419ec5056da@suse.cz \
--to=vbabka@suse.cz \
--cc=42.hyeyoo@gmail.com \
--cc=akinobu.mita@gmail.com \
--cc=andrii@kernel.org \
--cc=anil.s.keshavamurthy@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cl@linux.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox