From: Michal Hocko <mhocko@suse.com>
To: Chunyu Hu <chuhu@redhat.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
malat@debian.org, dvyukov@google.com, linux-mm@kvack.org,
catalin marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH] kmemleak: don't use __GFP_NOFAIL
Date: Wed, 30 May 2018 12:46:37 +0200 [thread overview]
Message-ID: <20180530104637.GC27180@dhcp22.suse.cz> (raw)
In-Reply-To: <1730157334.5467848.1527672937617.JavaMail.zimbra@redhat.com>
On Wed 30-05-18 05:35:37, Chunyu Hu wrote:
[...]
> I'm trying to reuse the make_it_fail field in task for fault injection. As adding
> an extra memory alloc flag is not thought so good, I think adding task flag
> is either?
Yeah, task flag will be reduced to KMEMLEAK enabled configurations
without an additional maint. overhead. Anyway, you should really think
about how to guarantee trackability for atomic allocation requests. You
cannot simply assume that GFP_NOWAIT will succeed. I guess you really
want to have a pre-populated pool of objects for those requests. The
obvious question is how to balance such a pool. It ain't easy to track
memory by allocating more memory...
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-05-30 10:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-26 7:14 WARNING: CPU: 0 PID: 21 at ../mm/page_alloc.c:4258 __alloc_pages_nodemask+0xa88/0xfec Mathieu Malaterre
2018-05-28 8:34 ` Michal Hocko
2018-05-28 13:05 ` [PATCH] kmemleak: don't use __GFP_NOFAIL Tetsuo Handa
2018-05-28 13:24 ` Michal Hocko
2018-05-28 21:05 ` Tetsuo Handa
2018-05-29 13:27 ` Chunyu Hu
2018-05-29 13:46 ` Tetsuo Handa
2018-05-30 9:35 ` Chunyu Hu
2018-05-30 10:46 ` Michal Hocko [this message]
2018-05-30 11:42 ` Chunyu Hu
2018-05-30 12:38 ` Michal Hocko
2018-05-31 10:51 ` Chunyu Hu
2018-05-31 11:35 ` Michal Hocko
2018-05-31 12:28 ` Chunyu Hu
2018-05-31 15:22 ` Catalin Marinas
2018-05-31 18:41 ` Michal Hocko
2018-06-01 1:50 ` Chunyu Hu
2018-06-01 4:53 ` Chunyu Hu
2018-06-04 8:41 ` Dmitry Vyukov
2018-06-04 12:42 ` Michal Hocko
2018-06-04 15:08 ` Catalin Marinas
2018-06-04 15:36 ` Dmitry Vyukov
2018-06-04 16:41 ` Catalin Marinas
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=20180530104637.GC27180@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=catalin.marinas@arm.com \
--cc=chuhu@redhat.com \
--cc=dvyukov@google.com \
--cc=linux-mm@kvack.org \
--cc=malat@debian.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.