Vlastimil Babka <vbabka@xxxxxxx> 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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>