From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-mm <linux-mm@kvack.org>, brouer@redhat.com
Subject: Re: Memory exhaustion testing?
Date: Mon, 16 Nov 2015 15:43:32 +0100 [thread overview]
Message-ID: <20151116154332.3f8fd151@redhat.com> (raw)
In-Reply-To: <5646EF73.5010005@I-love.SAKURA.ne.jp>
On Sat, 14 Nov 2015 17:23:15 +0900
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
> On 2015/11/13 5:55, Jesper Dangaard Brouer wrote:
> > Hi MM-people,
> >
> > How do you/we test the error paths when the system runs out of memory?
> >
> > What kind of tools do you use?
> > or Any tricks to provoke this?
>
> I use SystemTap for injecting memory allocation failure.
>
> http://lkml.kernel.org/r/201503182136.EJC90660.QSFOVJFOLHFOtM@I-love.SAKURA.ne.jp
>
> >
> > For testing my recent change to the SLUB allocator, I've implemented a
> > crude kernel module that tries to allocate all memory, so I can test the
> > error code-path in kmem_cache_alloc_bulk.
> >
> > see:
> > https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test04_exhaust_mem.c
> >
>
> I think you can test the error code-path in kmem_cache_alloc_bulk as
> well.
Yes, making __alloc_pages_nodemask() fail should propagate all the way
back into kmem_cache_alloc_bulk().
I do like your approach, but I think my use-case can be covered by
CONFIG_FAIL_PAGE_ALLOC (which like you, also hook into __alloc_pages_nodemask).
Although it seems I have more control with your approach, to filter in
which situations it should happen in.
Thanks for your input! :-)
--
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>
prev parent reply other threads:[~2015-11-16 14:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 20:55 Memory exhaustion testing? Jesper Dangaard Brouer
2015-11-13 22:54 ` David Rientjes
2015-11-16 14:24 ` Jesper Dangaard Brouer
2015-11-17 13:21 ` Jesper Dangaard Brouer
2015-11-19 20:40 ` David Rientjes
2015-11-20 13:09 ` Jesper Dangaard Brouer
2015-11-20 23:23 ` David Rientjes
2015-11-20 23:28 ` Andrew Morton
2015-11-14 8:23 ` Tetsuo Handa
2015-11-16 14:43 ` Jesper Dangaard Brouer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151116154332.3f8fd151@redhat.com \
--to=brouer@redhat.com \
--cc=linux-mm@kvack.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.