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 (Was: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.6-151-g8e794e9)


On 09/27/2011 07:52 AM, Mark Wielaard wrote:
> Hi David,
> 
> On Thu, 2011-09-01 at 14:39 +0000, dsmith@sourceware.org wrote:
>> commit 8e794e9dfeea5a48b84442b92dea6c17b9ef75d1
>> Author: David Smith <dsmith@redhat.com>
>> Date:   Thu Sep 1 09:39:15 2011 -0500
>>
>>     Fixed PR13146 by not allowing memory allocations to sleep.
>>     
>>     * runtime/alloc.c:  Turn off __GFP_WAIT when allocating memory.
>>     * runtime/transport/ring_buffer.c (__stp_alloc_ring_buffer): Ditto.
>>     * runtime/counter.c (_stp_counter_init): Handles memory allocation failure
>>       better.
>>     * runtime/task_finder.c (__stp_call_mmap_callbacks_with_addr): Better
>>       cleanup if memory allocation fails.
> 
> Sorry for the late reply. But I am suspecting this commit of causing
> accasional (though not very frequent) test failures that say:
>   ERROR: context (size 8352) allocation failed
> 
> I suspect that is caused because the context is one of the larger
> allocations at systemtap_module_init time. And because we are no longer
> allowed to GFP_WAIT it is more likely to fail now. Would it be
> possible/make sense to allow GFP_WAIT for allocations made from context
> like systemtap_module_init() that may sleep because they are made from
> user context?

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.

Josh


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