This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Fixed PR13146 by not allowing memory allocations to sleep
- From: Mark Wielaard <mjw at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Josh Stone <jistone at redhat dot com>, systemtap at sourceware dot org, dsmith at redhat dot com
- Date: Tue, 25 Oct 2011 14:18:43 +0200
- Subject: Re: Fixed PR13146 by not allowing memory allocations to sleep
- References: <20110901143940.13672.qmail@sourceware.org> <1317135124.3361.22.camel@springer.wildebeest.org> <4E82481E.8060502@redhat.com> <y0m39ehwa02.fsf@fche.csb>
On Tue, 2011-10-25 at 08:06 -0400, Frank Ch. Eigler wrote:
> jistone wrote:
>
> > [...]
> > I agree, those contexts which can sleep, should. Not only does this
> > make it more likely we'll get the memory we want, but also makes us
> > better citizens with the rest of the kernel.
>
> Unfortunately, that's not quite sound policy either. The memory
> allocation aggressiveness pendulum has swung too far with the new
> code, and now large data structures are allocated with plain
> GFP_KERNEL. On small-memory machines, this is found to OOM the
> system, rather than let the stap module give up early.
>
> An intermediate approach is needed; maybe __GFP_REPEAT & !__GFP_NOWAIT.
Probably the best approach is the introduce a specific
STP_ALLOC_FLAGS_WAIT, STP_ALLOC_FLAGS_NOWAIT in runtime/alloc.c to
replace the generic STP_ALLOC_FLAGS and GFP_KERNEL we are now using. The
first would be for "normal" allocations, which may wait, can fail, etc
(just don't trigger the oom-killer) and the later would be for critical
allocations in context that cannot wait.
I cannot find what precisely triggers/causes the oom-killer to kick in.
I hoped a GFP_WILLING_TO_WAIT_BUT_DONT_KILL_ANYBODY_JUST_BECAUSE_OF_ME
flag would exist, but it isn't clear to me which GFP flag/combination
that actually corresponds to.
Cheers,
Mark