From: Uladzislau Rezki <urezki@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Ilya Dryomov <idryomov@gmail.com>,
Jeff Layton <jlayton@kernel.org>
Subject: Re: [PATCH 2/4] mm/vmalloc: add support for __GFP_NOFAIL
Date: Fri, 29 Oct 2021 16:05:32 +0200 [thread overview]
Message-ID: <CA+KHdyX_0B-hM8m0eZBetcdBC9X3ddnA4dMyZvA2_xCjJJeJCA@mail.gmail.com> (raw)
In-Reply-To: <YXupZjQgLAi6ClRi@dhcp22.suse.cz>
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index d77830ff604c..f4b7927e217e 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -2889,8 +2889,14 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > unsigned long array_size;
> > unsigned int nr_small_pages = size >> PAGE_SHIFT;
> > unsigned int page_order;
> > + unsigned long flags;
> > + int ret;
> >
> > array_size = (unsigned long)nr_small_pages * sizeof(struct page *);
> > +
> > + /*
> > + * This is i do not understand why we do not want to see warning messages.
> > + */
> > gfp_mask |= __GFP_NOWARN;
>
> I suspect this is becauser vmalloc wants to have its own failure
> reporting.
>
But as i see it is broken. All three warn_alloc() reports in the
__vmalloc_area_node()
are useless because the __GFP_NOWARN is added on top of gfp_mask:
void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...)
{
struct va_format vaf;
va_list args;
static DEFINE_RATELIMIT_STATE(nopage_rs, 10*HZ, 1);
if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(&nopage_rs))
return;
...
everything with the __GFP_NOWARN is just reverted.
> [...]
> > @@ -3010,16 +3037,22 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
> > area = __get_vm_area_node(real_size, align, shift, VM_ALLOC |
> > VM_UNINITIALIZED | vm_flags, start, end, node,
> > gfp_mask, caller);
> > - if (!area) {
> > - warn_alloc(gfp_mask, NULL,
> > - "vmalloc error: size %lu, vm_struct allocation failed",
> > - real_size);
> > - goto fail;
> > - }
> > + if (area)
> > + addr = __vmalloc_area_node(area, gfp_mask, prot, shift, node);
> > +
> > + if (!area || !addr) {
> > + if (gfp_mask & __GFP_NOFAIL) {
> > + schedule_timeout_uninterruptible(1);
> > + goto again;
> > + }
> > +
> > + if (!area)
> > + warn_alloc(gfp_mask, NULL,
> > + "vmalloc error: size %lu, vm_struct allocation failed",
> > + real_size);
> >
> > - addr = __vmalloc_area_node(area, gfp_mask, prot, shift, node);
> > - if (!addr)
> > goto fail;
> > + }
> >
> > /*
> > * In this function, newly allocated vm_struct has VM_UNINITIALIZED
> > <snip>
>
> OK, this looks easier from the code reading but isn't it quite wasteful
> to throw all the pages backing the area (all of them allocated as
> __GFP_NOFAIL) just to then fail to allocate few page tables pages and
> drop all of that on the floor (this will happen in __vunmap AFAICS).
>
> I mean I do not care all that strongly but it seems to me that more
> changes would need to be done here and optimizations can be done on top.
>
> Is this something you feel strongly about?
>
Will try to provide some motivations :)
It depends on how to look at it. My view is as follows a more simple code
is preferred. It is not considered as a hot path and it is rather a corner
case to me. I think "unwinding" has some advantage. At least one motivation
is to release a memory(on failure) before a delay that will prevent holding
of extra memory in case of __GFP_NOFAIL infinitelly does not succeed, i.e.
if a process stuck due to __GFP_NOFAIL it does not "hold" an extra memory
forever.
--
Uladzislau Rezki
next prev parent reply other threads:[~2021-10-29 14:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 15:02 [PATCH 0/4] extend vmalloc support for constrained allocations Michal Hocko
2021-10-25 15:02 ` [PATCH 1/4] mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc Michal Hocko
2021-10-25 15:02 ` [PATCH 2/4] mm/vmalloc: add support for __GFP_NOFAIL Michal Hocko
2021-10-25 22:59 ` NeilBrown
2021-10-26 7:03 ` Michal Hocko
2021-10-26 10:30 ` NeilBrown
2021-10-26 11:29 ` Michal Hocko
2021-10-26 15:48 ` Uladzislau Rezki
2021-10-26 16:28 ` Michal Hocko
2021-10-26 19:33 ` Uladzislau Rezki
2021-10-27 6:46 ` Michal Hocko
2021-10-27 17:55 ` Uladzislau Rezki
2021-10-29 7:57 ` Michal Hocko
2021-10-29 14:05 ` Uladzislau Rezki [this message]
2021-10-29 14:45 ` Michal Hocko
2021-10-29 17:23 ` Uladzislau Rezki
2021-10-25 15:02 ` [PATCH 3/4] mm/vmalloc: be more explicit about supported gfp flags Michal Hocko
2021-10-25 23:26 ` NeilBrown
2021-10-26 7:10 ` Michal Hocko
2021-10-26 10:43 ` NeilBrown
2021-10-26 12:20 ` Michal Hocko
2021-10-25 15:02 ` [PATCH 4/4] mm: allow !GFP_KERNEL allocations for kvmalloc Michal Hocko
2021-10-25 23:34 ` NeilBrown
2021-10-26 7:15 ` Michal Hocko
2021-10-26 10:48 ` NeilBrown
2021-10-26 12:23 ` Michal Hocko
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=CA+KHdyX_0B-hM8m0eZBetcdBC9X3ddnA4dMyZvA2_xCjJJeJCA@mail.gmail.com \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=neilb@suse.de \
/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).