This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fixed PR13146 by not allowing memory allocations to sleep


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]