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 14:18 +0200, Mark Wielaard wrote:
> 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.

Looking at the kernel sources it seems that flag is __GFP_NORETRY.
Though that isn't a guarantee, it depends on the memory backend. Still
it seems to prevent the oom-killer being triggered on my small memory
setup. So I created STP_ALLOC_SLEEP_FLAGS that includes that flag and
use that whenever we do _stp_alloc request from user context. Note that
this isn't a full "solution" to the oom-killer kicking in. There are
places where GFP_KERNEL is used that we don't control.

commit 6022ccd4cab89944ca390c23de13cdc54cf05b1f
Author: Mark Wielaard <mjw@redhat.com>
Date:   Mon Oct 31 10:39:10 2011 +0100

Introduce and use STP_ALLOC_SLEEP_FLAGS for use with gfp alloc
functions.
    
When in a context where we can wait we like to use normal GFP_KERNEL.
But this might trigger the oom-killer, which might kill out own stapio
process. To suppress this use __GFP_NORETRY. All _stp_[kmz]alloc_gfp
functions that are used in user context should use STP_ALLOC_SLEEP_FLAGS
if appropriate.
    
Note that the kernel itself may still use GFP_KERNEL. For example
__alloc_percpu() will always use GFP_KERNEL.


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