linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	tom@quantonium.net, linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags
Date: Mon, 4 Jun 2018 08:37:50 +0200	[thread overview]
Message-ID: <20180604063750.GB19202@dhcp22.suse.cz> (raw)
In-Reply-To: <CA+55aFwaYEn8rA=-8hi1v8wWiLGJJsvkuEvBOxgvnmfUBfg4Vg@mail.gmail.com>

On Sat 02-06-18 09:43:56, Linus Torvalds wrote:
> On Fri, Jun 1, 2018 at 4:53 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > for more context. Linus has pointed out [1] that our (well mine)
> > insisting on GFP_KERNEL compatible gfp flags for kvmalloc* can actually
> > lead to a worse code because people will work around the restriction.
> > So this patch allows kvmalloc to be more permissive and silently skip
> > vmalloc path for incompatible gfp flags.
> 
> Ack.
> 
> > This will not help my original
> > plan to enforce people to think about GFP_NOFS usage more deeply but
> > I can live with that obviously...
> 
> Is it NOFS in particular you care about?

Yes, mostly.

> The only reason for that
> should be the whole "don't recurse", and I think the naming is
> historical and slightly odd.
> 
> It was historically just about allocations that were in the writeout
> path for a block layer or filesystem - and the name made sense in that
> context. These days, I think it's just shorthand for "you can do
> simple direct reclaim from the mm itself, but you can't  block or call
> anything else".

It is still mostly used by fs code these days. There are few exceptions
though. David Chinner mentioned some DRM code which does use NOFS to
prevent recursing into their slab shrinkers.

> So I think the name and the semantics are a bit unclear, but it's
> obviously still useful.

agreed
 
> It's entirely possible that direct reclaim should never do any of the
> more complicated callback cases anyway, but we'd still need the whole
> "don't wait for the complex case" logic to avoid deadlocks.

This is problematic because we can sit on a huge amount of reclaimable
memory and the direct reclaim is the only context to trigger the oom
killer so we have to either find some other way to do the same or invoke
even the complex reclaimers. My long term plan was to convert direct NOFS
users to the scope API (see memalloc_no{fs,io}_{save,restore}) which
would mark "reclaim recursion critical sections" and all allocations
within that scope would not trigger shrinkers that could deadlock. The
current API is quite coarse but there are plans to make it more fine
grained.

Anyway, this is not directly related to this patch. Current kvmalloc
users seem to be GFP_KERNEL compliant. Let's hope it stays that way.
-- 
Michal Hocko
SUSE Labs

      reply	other threads:[~2018-06-04  6:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01 11:53 [PATCH] mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags Michal Hocko
2018-06-02 16:43 ` Linus Torvalds
2018-06-04  6:37   ` Michal Hocko [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=20180604063750.GB19202@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tom@quantonium.net \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).