Re: Memory exhaustion testing?

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Mon, 16 Nov 2015 15:24:40 +0100 Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> On Fri, 13 Nov 2015 14:54:37 -0800 (PST) David Rientjes <rientjes@google.com> wrote:
> 
> > [...]  This is why 
> > failslab had been used in the past, and does a good job at runtime 
> > testing.  
> 
> Thanks for mentioning CONFIG_FAILSLAB.  First I disregarded
> "failslab" (I did notice it in the slub code) because it didn't
> exercised the code path I wanted in kmem_cache_alloc_bulk().
> 
> But went to looking up the config setting I notice that we do have a
> hole section for "Fault-injection".  Which is great, and what I was
> looking for.
> 
> Menu config Location:
>  -> Kernel hacking
>   -> Fault-injection framework (FAULT_INJECTION [=y])
> 
> I think what I need can be covered by FAIL_PAGE_ALLOC, or should_fail_alloc_page().
> I'll try and play a bit with it...

I did manage to provoke/test the error path in kmem_cache_alloc_bulk(),
by using fault-injection framework "fail_page_alloc".

But was a little hard to trigger SLUB errors with this, because SLUB
retries after a failure, and second call to alloc_pages() is done with
lower order.

If order is lowered to zero, then should_fail_alloc_page() will skip it.
And just lowering /sys/kernel/debug/fail_page_alloc/min-order=0 is not
feasible as even fork starts to fail.  I managed to work-around this by
using "space" setting.

Created a script to ease this tricky invocation:
 https://github.com/netoptimizer/prototype-kernel/blob/master/tests/fault-inject/fail01_kmem_cache_alloc_bulk.sh

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

--
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>