LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: vbabka@suse.cz, mhocko@suse.cz, hannes@cmpxchg.org
Cc: akpm@linux-foundation.org, david@fromorbit.com, mgorman@suse.de,
riel@redhat.com, fengguang.wu@intel.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2 v2] mm: Allow small allocations to fail
Date: Wed, 18 Mar 2015 21:36:33 +0900 [thread overview]
Message-ID: <201503182136.EJC90660.QSFOVJFOLHFOtM@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <5509410F.2080000@suse.cz>
Vlastimil Babka wrote:
> I'll add that I think if we do improve the reclaim etc, and make
> allocations failures rarer, then the whole testing effort will have much
> lower chance of finding the places where allocation failures are not
> handled properly. Also Michal says that catching those depend on running
> all "their loads which we never dreamed of". In that case, if our goal
> is to fix all broken allocation sites with some quantifiable
> probability, I'm afraid we might be really better off with some form of
> fault injection, which will trigger the failures with the probability we
> set, and not depend on corner case low memory conditions manifesting
> just at the time the workload is at one of the broken allocation sites.
>
I think we can use SystemTap based fault injection which allows only once
injection per each backtrace without putting the system under OOM condition,
which I demonstrated at https://lkml.org/lkml/2014/12/25/64 .
Since SystemTap can generate backtraces without garbage lines,
we can uniquely identify and inject only once per each backtrace,
making it possible to test every memory allocation callers.
Steps for installation and testing are described below.
---------- installation start ----------
wget https://sourceware.org/systemtap/ftp/releases/systemtap-2.7.tar.gz
echo 'e0c3c36955323ae59be07a26a9563474 systemtap-2.7.tar.gz' | md5sum --check -
tar -zxf systemtap-2.7.tar.gz
cd systemtap-2.7
./configure --prefix=$HOME/systemtap.tmp
make -s
make -s install
---------- installation end ----------
---------- preparation (optional) start ----------
Start kdump service and set /proc/sys/kernel/panic_on_oops to 1
as root user so that we can obtain vmcore upon kernel oops.
---------- preparation (optional) end ----------
---------- testing start ----------
Run
$HOME/systemtap.tmp/bin/staprun fault_injection.ko
and operate as you like, and see whether your system can survive or not.
---------- testing end ----------
The fault_injection.ko is generated by commands shown below.
Scripts shown below checks only sleepable allocations. If you
replace %{ __GFP_WAIT %} with 0, you can check atomic allocations.
---------- For testing __kmalloc() failure ----------
$HOME/systemtap.tmp/bin/stap -p4 -m fault_injection -g -DSTP_NO_OVERLOAD -e '
global traces_bt[65536];
probe begin { printf("Probe start!\n"); }
probe kernel.function("__kmalloc") {
if (($flags & %{ __GFP_NOFAIL | __GFP_WAIT %} ) == %{ __GFP_WAIT %} && execname() != "stapio") {
bt = backtrace();
if (traces_bt[bt]++ == 0) {
printf("%s (%u) size:%u gfp:0x%x\n", execname(), tid(), $size, $flags);
print_stack(bt);
printf("\n\n");
$size = 1 << 30;
}
}
}
probe end { delete traces_bt; }'
---------- For testing __kmalloc() failure ----------
Like an example shown below demonstrate, we will be able to selectively
test specific subsystems by setting per a task_struct marker.
---------- For testing __alloc_pages_nodemask() failure except page fault ----------
$HOME/systemtap.tmp/bin/stap -p4 -m fault_injection -g -DSTP_NO_OVERLOAD -e '
global traces_bt[65536];
global in_page_fault%;
probe begin { printf("Probe start!\n"); }
probe kernel.function("__alloc_pages_nodemask") {
if (($gfp_mask & %{ __GFP_NOFAIL | __GFP_WAIT %} ) == %{ __GFP_WAIT %} &&
in_page_fault[tid()] == 0 && execname() != "stapio") {
bt = backtrace();
if (traces_bt[bt]++ == 0) {
printf("%s (%u) order:%u gfp:0x%x\n", execname(), tid(), $order, $gfp_mask);
print_stack(bt);
printf("\n\n");
$order = 1 << 30;
$gfp_mask = $gfp_mask | %{ __GFP_NORETRY %};
}
}
}
probe kernel.function("handle_mm_fault") {
in_page_fault[tid()]++;
}
probe kernel.function("handle_mm_fault").return {
in_page_fault[tid()]--;
}
probe end { delete traces_bt; delete in_page_fault; }'
---------- For testing __alloc_pages_nodemask() failure except page fault ----------
next prev parent reply other threads:[~2015-03-18 12:36 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 20:54 [PATCH 0/2] Move away from non-failing small allocations Michal Hocko
2015-03-11 20:54 ` [PATCH 1/2] mm: Allow small allocations to fail Michal Hocko
2015-03-12 12:54 ` Tetsuo Handa
2015-03-12 13:12 ` Michal Hocko
2015-03-15 5:43 ` Tetsuo Handa
2015-03-15 12:13 ` Michal Hocko
2015-03-15 13:06 ` Tetsuo Handa
2015-03-16 7:46 ` [PATCH 1/2 v2] " Michal Hocko
2015-03-16 21:11 ` Johannes Weiner
2015-03-17 10:25 ` Michal Hocko
2015-03-17 13:29 ` Johannes Weiner
2015-03-17 14:17 ` Michal Hocko
2015-03-17 17:26 ` Johannes Weiner
2015-03-17 19:41 ` Michal Hocko
2015-03-18 9:10 ` Vlastimil Babka
2015-03-18 12:04 ` Michal Hocko
2015-03-18 12:36 ` Tetsuo Handa [this message]
2015-03-18 11:35 ` Tetsuo Handa
2015-03-17 11:13 ` Tetsuo Handa
2015-03-17 13:15 ` Michal Hocko
2015-03-18 11:33 ` Tetsuo Handa
2015-03-18 12:23 ` Michal Hocko
2015-03-19 11:03 ` Tetsuo Handa
2015-03-11 20:54 ` [PATCH 2/2] mmotm: Enable small allocation " Michal Hocko
2015-03-11 22:36 ` [PATCH 0/2] Move away from non-failing small allocations Sasha Levin
2015-03-16 22:38 ` Andrew Morton
2015-03-17 9:07 ` Michal Hocko
2015-03-17 14:06 ` Tetsuo Handa
2015-04-02 11:53 ` Tetsuo Handa
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=201503182136.EJC90660.QSFOVJFOLHFOtM@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=riel@redhat.com \
--cc=vbabka@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).