From: Michal Hocko <mhocko@suse.com>
To: Barry Song <21cnbao@gmail.com>, Davidlohr Bueso <dave@stgolabs.net>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
42.hyeyoo@gmail.com, cl@linux.com, hch@infradead.org,
iamjoonsoo.kim@lge.com, lstoakes@gmail.com, penberg@kernel.org,
rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com,
v-songbaohua@oppo.com, vbabka@suse.cz,
virtualization@lists.linux.dev, hailong.liu@oppo.com,
torvalds@linux-foundation.org
Subject: Re: [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL
Date: Thu, 25 Jul 2024 08:16:34 +0200 [thread overview]
Message-ID: <ZqHtwqyj4seB-eut@tiehlicka> (raw)
In-Reply-To: <CAGsJ_4x1k-z7OcQPSgqXhxTM8Z_D3Og6mGkC1pWu2+pR3YRKvw@mail.gmail.com>
On Thu 25-07-24 13:38:50, Barry Song wrote:
> On Thu, Jul 25, 2024 at 12:17 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Wed 24-07-24 20:55:44, Barry Song wrote:
> > > From: Barry Song <v-songbaohua@oppo.com>
> > >
> > > GFP_NOFAIL includes the meaning of block and direct reclamation, which
> > > is essential for a true no-fail allocation. We are gradually starting
> > > to enforce this block semantics to prevent the potential misuse of
> > > __GFP_NOFAIL in atomic contexts in the future.
> > >
> > > A typical example of incorrect usage is in VDPA, where GFP_ATOMIC
> > > and __GFP_NOFAIL are used together.
> >
> > Ohh, so you have done the migration. Please squash those two patches.
> > Also if we want to preserve clean __GFP_NOFAIL for internal MM use then it
> > should be moved away from include/linux/gfp_types.h. But is there any
> > real use for that?
>
> yes. currently i got two,
>
> lib/rhashtable.c
>
> static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
> size_t nbuckets,
> gfp_t gfp)
> {
> struct bucket_table *tbl = NULL;
> size_t size;
> int i;
> static struct lock_class_key __key;
>
> tbl = alloc_hooks_tag(ht->alloc_tag,
> kvmalloc_node_noprof(struct_size(tbl, buckets,
> nbuckets),
> gfp|__GFP_ZERO, NUMA_NO_NODE));
>
> size = nbuckets;
>
> if (tbl == NULL && (gfp & ~__GFP_NOFAIL) != GFP_KERNEL) {
> tbl = nested_bucket_table_alloc(ht, nbuckets, gfp);
> nbuckets = 0;
> }
>
> ...
>
> return tbl;
> }
Ugh. OK this is a weird allocation fallback strategy 2d22ecf6db1c
("lib/rhashtable: guarantee initial hashtable allocation"). Maybe the
code should be just simplified and GFP_NOFAIL used from the begining?
Davidlohr WDYT? For your context Barry tries to drop all the
__GFP_NOFAIL use and replace it by GFP_NOFAIL which enforces
__GFP_DIRECT_RECLAIM so that people cannot request atomic NOFAIL.
> and tools/perf/builtin-kmem.c:
>
> static const struct {
> const char *original;
> const char *compact;
> } gfp_compact_table[] = {
> { "GFP_TRANSHUGE", "THP" },
> { "GFP_TRANSHUGE_LIGHT", "THL" },
> { "GFP_HIGHUSER_MOVABLE", "HUM" },
> { "GFP_HIGHUSER", "HU" },
> ...
> { "__GFP_NOFAIL", "NF" },
> ...
> };
This is a prrintk formatting stuff. This counts as low level
functionality.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-07-25 6:16 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 8:55 [PATCH 0/5] mm: clarify nofail memory allocation Barry Song
2024-07-24 8:55 ` [PATCH RFC 1/5] vpda: try to fix the potential crash due to misusing __GFP_NOFAIL Barry Song
2024-07-24 12:26 ` Michal Hocko
2024-07-24 22:50 ` Barry Song
2024-07-25 6:08 ` Michal Hocko
2024-07-25 7:00 ` Barry Song
2024-07-29 3:42 ` Jason Wang
2024-07-29 6:05 ` Barry Song
2024-07-30 2:48 ` Jason Wang
2024-07-30 3:08 ` Barry Song
2024-07-30 3:13 ` Jason Wang
2024-07-24 8:55 ` [PATCH 2/5] mm: Document __GFP_NOFAIL must be blockable Barry Song
2024-07-24 11:58 ` Michal Hocko
2024-08-03 23:09 ` Davidlohr Bueso
2024-07-24 8:55 ` [PATCH 3/5] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails Barry Song
2024-07-24 10:03 ` Vlastimil Babka
2024-07-24 10:11 ` Barry Song
2024-07-24 12:10 ` Michal Hocko
2024-07-24 8:55 ` [PATCH 4/5] mm: Introduce GFP_NOFAIL with the inclusion of __GFP_RECLAIM Barry Song
2024-07-24 12:12 ` Michal Hocko
2024-07-24 8:55 ` [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL Barry Song
2024-07-24 9:53 ` Vlastimil Babka
2024-07-24 9:58 ` Barry Song
2024-07-24 13:14 ` Christoph Hellwig
2024-07-24 12:25 ` Michal Hocko
2024-07-24 13:13 ` Christoph Hellwig
2024-07-24 13:21 ` Michal Hocko
2024-07-24 13:23 ` Christoph Hellwig
2024-07-24 13:31 ` Michal Hocko
2024-07-24 13:33 ` Vlastimil Babka
2024-07-24 13:38 ` Christoph Hellwig
2024-07-24 13:47 ` Michal Hocko
2024-07-24 13:55 ` Christoph Hellwig
2024-07-24 14:39 ` Vlastimil Babka
2024-07-24 14:41 ` Christoph Hellwig
2024-07-25 1:47 ` Barry Song
2024-07-29 9:56 ` Barry Song
2024-07-29 10:03 ` Vlastimil Babka
2024-07-29 10:16 ` Barry Song
2024-07-24 12:17 ` Michal Hocko
2024-07-25 1:38 ` Barry Song
2024-07-25 6:16 ` Michal Hocko [this message]
2024-07-26 21:08 ` Davidlohr Bueso
2024-07-29 11:50 ` Michal Hocko
2024-08-03 22:15 ` Davidlohr Bueso
2024-08-05 7:49 ` Michal Hocko
2024-07-25 1:17 ` kernel test robot
2024-07-25 14:20 ` Dan Carpenter
-- strict thread matches above, loose matches on Subject: below --
2024-07-25 6:38 kernel test robot
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=ZqHtwqyj4seB-eut@tiehlicka \
--to=mhocko@suse.com \
--cc=21cnbao@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dave@stgolabs.net \
--cc=hailong.liu@oppo.com \
--cc=hch@infradead.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=torvalds@linux-foundation.org \
--cc=urezki@gmail.com \
--cc=v-songbaohua@oppo.com \
--cc=vbabka@suse.cz \
--cc=virtualization@lists.linux.dev \
/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.