From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org
Cc: hannes@cmpxchg.org, akpm@linux-foundation.org,
alan@llwyncelyn.cymru, hch@lst.de, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] vmalloc: back off only when the current task is OOM killed
Date: Tue, 10 Oct 2017 23:13:21 +0900 [thread overview]
Message-ID: <201710102313.DBB60400.QOOVHLFJFOtMFS@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20171010134916.x5iskqymwjj6akpo@dhcp22.suse.cz>
Michal Hocko wrote:
> On Tue 10-10-17 21:47:02, Tetsuo Handa wrote:
> > I think that massive vmalloc() consumers should be (as well as massive
> > alloc_page() consumers) careful such that they will be chosen as first OOM
> > victim, for vmalloc() does not abort as soon as an OOM occurs.
>
> No. This would require to spread those checks all over the place. That
> is why we have that logic inside the allocator which fails the
> allocation at certain point in time. Large/unbound/user controlled sized
> allocations from the kernel are always a bug and really hard one to
> protect from. It is simply impossible to know the intention.
>
> > Thus, I used
> > set_current_oom_origin()/clear_current_oom_origin() when I demonstrated
> > "complete" depletion.
>
> which was a completely artificial example as already mentioned.
>
> > > I have tried to explain this is not really needed before but you keep
> > > insisting which is highly annoying. The patch as is is not harmful but
> > > it is simply _pointless_ IMHO.
> >
> > Then, how can massive vmalloc() consumers become careful?
> > Explicitly use __vmalloc() and pass __GFP_NOMEMALLOC ?
> > Then, what about adding some comment like "Never try to allocate large
> > memory using plain vmalloc(). Use __vmalloc() with __GFP_NOMEMALLOC." ?
>
> Come on! Seriously we do expect some competence from the code running in
> the kernel space. We do not really need to add a comment that you
> shouldn't shoot your head because it might hurt. Please try to focus on
> real issues. There are many of them to chase after...
>
My understanding is that vmalloc() is provided for allocating large memory
where kmalloc() is difficult to satisfy. If we say "do not allocate large
memory with vmalloc() because large allocations from the kernel are always
a bug", it sounds like denial of raison d'etre of vmalloc(). Strange...
But anyway, I am not bothered by vmalloc(). What I'm bothered is warn_alloc()
lockup. Please go ahead with removal of fatal_signal_pending() for vmalloc().
--
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>
next prev parent reply other threads:[~2017-10-10 14:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-10 10:58 Tetsuo Handa
2017-10-10 11:54 ` Michal Hocko
2017-10-10 12:47 ` Tetsuo Handa
2017-10-10 13:49 ` Michal Hocko
2017-10-10 14:13 ` Tetsuo Handa [this message]
2017-10-10 14:17 ` Michal Hocko
2017-10-10 12:47 ` Johannes Weiner
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=201710102313.DBB60400.QOOVHLFJFOtMFS@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=alan@llwyncelyn.cymru \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox