Re: More OOM problems

[Andi Kleen <andi@firstfloor.org>]

Vlastimil Babka <vbabka@suse.cz> writes:
>> 
>> The trigger is a kcalloc() in the i915 driver:
>> 
>>     Xorg invoked oom-killer:
>> gfp_mask=0x240c0d0(GFP_TEMPORARY|__GFP_COMP|__GFP_ZERO), order=3,
>> oom_score_adj=0
>> 
>>       __kmalloc+0x1cd/0x1f0
>>       alloc_gen8_temp_bitmaps+0x47/0x80 [i915]
>> 
>> which looks like it is one of these:
>> 
>>   slabinfo - version: 2.1
>>   # name            <active_objs> <num_objs> <objsize> <objperslab>
>> <pagesperslab>
>>   kmalloc-8192         268    268   8192    4    8
>>   kmalloc-4096         732    786   4096    8    8
>>   kmalloc-2048        1402   1456   2048   16    8
>>   kmalloc-1024        2505   2976   1024   32    8
>> 
>> so even just a 1kB allocation can cause an order-3 page allocation.
>
> Sounds like SLUB. SLAB would use order-0 as long as things fit. I would
> hope for SLUB to fallback to order-0 (or order-1 for 8kB) instead of
> OOM, though. Guess not...

It's already trying to do that, perhaps just some flags need to be
changed?

Adding Christoph.

	flags |= s->allocflags;

	/*
	 * Let the initial higher-order allocation fail under memory pressure
	 * so we fall-back to the minimum order allocation.
	 */
	alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;

	page = alloc_slab_page(alloc_gfp, node, oo);
	if (unlikely(!page)) {
		oo = s->min;
		/*
		 * Allocation may have failed due to fragmentation.
		 * Try a lower order alloc if possible
		 */
		page = alloc_slab_page(flags, node, oo);

		if (page)
			stat(s, ORDER_FALLBACK);
	}


-Andi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>