From: Uladzislau Rezki <urezki@gmail.com>
To: Jaeseon Sim <jason.sim@samsung.com>
Cc: Uladzislau Rezki <urezki@gmail.com>,
"bhe@redhat.com" <bhe@redhat.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"hch@infradead.org" <hch@infradead.org>,
"lstoakes@gmail.com" <lstoakes@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jaewon Kim <jaewon31.kim@samsung.com>
Subject: Re: [PATCH] mm/vmalloc: Remove WARN_ON_ONCE related to adjust_va_to_fit_type
Date: Tue, 26 Sep 2023 14:35:21 +0200 [thread overview]
Message-ID: <ZRLQCTh9zNIp9OH7@pc636> (raw)
In-Reply-To: <20230926120549epcms1p4d41733c1c3698bd00eaa7e5ea0de041d@epcms1p4>
On Tue, Sep 26, 2023 at 09:05:49PM +0900, Jaeseon Sim wrote:
> > > > We do not have above code anymore:
> > > Sorry, I tried to say it in a simplified way and it caused a misunderstanding.
> > >
> > > <snip>
> > > static __always_inline int
> > > adjust_va_to_fit_type(struct rb_root *root, struct list_head *head,
> > > struct vmap_area *va, unsigned long nva_start_addr,
> > > unsigned long size)
> > >
> > > } else if (type == NE_FIT_TYPE) {
> > > /*
> > > * Split no edge of fit VA.
> > > *
> > > * | |
> > > * L V NVA V R
> > > * |---|-------|---|
> > > */
> > > lva = __this_cpu_xchg(ne_fit_preload_node, NULL);
> > > if (unlikely(!lva)) {
> > > /*
> > > * For percpu allocator we do not do any pre-allocation
> > > * and leave it as it is. The reason is it most likely
> > > * never ends up with NE_FIT_TYPE splitting. In case of
> > > * percpu allocations offsets and sizes are aligned to
> > > * fixed align request, i.e. RE_FIT_TYPE and FL_FIT_TYPE
> > > * are its main fitting cases.
> > > *
> > > * There are a few exceptions though, as an example it is
> > > * a first allocation (early boot up) when we have "one"
> > > * big free space that has to be split.
> > > *
> > > * Also we can hit this path in case of regular "vmap"
> > > * allocations, if "this" current CPU was not preloaded.
> > > * See the comment in alloc_vmap_area() why. If so, then
> > > * GFP_NOWAIT is used instead to get an extra object for
> > > * split purpose. That is rare and most time does not
> > > * occur.
> > > *
> > > * What happens if an allocation gets failed. Basically,
> > > * an "overflow" path is triggered to purge lazily freed
> > > * areas to free some memory, then, the "retry" path is
> > > * triggered to repeat one more time. See more details
> > > * in alloc_vmap_area() function.
> > > */
> > > lva = kmem_cache_alloc(vmap_area_cachep, GFP_NOWAIT);
> > > if (!lva)
> > > return -1;
> > > }
> > > <snip>
> > >
> > > Above allocation fail will meet WARN_ON_ONCE in the current kernel now.
> > > Should It be handled by alloc_vmap_area()?, as you described in a comment.
> > >
> > WARN_ONCE_ONCE() is a warning and not a panic, though your kernel config
> > considers it as a panic. Right, we go on retry path and we can remove
>
> Right, only in case panic_on_warn is enabled..
>
> > the warning only for GFP_NOWAIT-alloc-error. From the other hand we
> > should still have possibility to trigger a warning if an allocation
> > is not successful: no vmap space or low memory condition, thus no
> > physical memory.
>
> Yes, but GFP_NOWAIT-alloc-error can easily occur for low-memory device.
>
Agree. You are really in a low memory condition. We end up here only if
pre-loading also has not succeeded, i.e. GFP_KERNEL also fails.
But i agree with you, we should "improve the warning" because we drain
and repeat.
> How about changing fix as below?:
>
> <snip>
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1468,6 +1468,7 @@ adjust_va_to_fit_type(struct rb_root *root, struct list_head *head,
> */
> va->va_start = nva_start_addr + size;
> } else {
> + WARN_ON_ONCE(1);
> return -1;
> }
>
> @@ -1522,7 +1523,7 @@ __alloc_vmap_area(struct rb_root *root, struct list_head *head,
>
> /* Update the free vmap_area. */
> ret = adjust_va_to_fit_type(root, head, va, nva_start_addr, size);
> - if (WARN_ON_ONCE(ret))
> + if (ret)
> return vend;
>
> #if DEBUG_AUGMENT_LOWEST_MATCH_CHECK
> @@ -4143,7 +4144,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
> ret = adjust_va_to_fit_type(&free_vmap_area_root,
> &free_vmap_area_list,
> va, start, size);
> - if (WARN_ON_ONCE(unlikely(ret)))
> + if (unlikely(ret))
> /* It is a BUG(), but trigger recovery instead. */
> goto recovery;
>
> <snip>
> It will WARN_ONCE_ONCE() only if classify_va_fit_type() is "(type == NOTHING_FIT)".
>
This is good but i think it should be improved further. We need to
understand from the warning when no memory and when there is no a
vmap space, so:
- if NOTHING_FIT, we should WARN() for sure;
- Second place in the pcpu_get_vm_area(), we do not use NE_FIT. Only in
the begging after boot, but potentially we can trigger -ENOMEM and we
should warn in this case. Otherwise you just hide it;
- And last one if after repeating we still do not manage to allocate.
--
Uladzislau Rezki
next prev parent reply other threads:[~2023-09-26 12:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230922061715epcms1p7cd5a37f4bba0abf4bc159b844bd8ee65@epcms1p1>
2023-09-22 6:27 ` [PATCH] mm/vmalloc: Remove WARN_ON_ONCE related to adjust_va_to_fit_type Jaeseon Sim
2023-09-22 9:34 ` bhe
2023-09-22 9:42 ` bhe
2023-09-25 10:51 ` Jaeseon Sim
2023-09-25 13:40 ` Uladzislau Rezki
2023-09-26 5:21 ` Jaeseon Sim
2023-09-26 6:05 ` Uladzislau Rezki
2023-09-26 12:05 ` Jaeseon Sim
2023-09-26 12:35 ` Uladzislau Rezki [this message]
2023-09-27 11:49 ` Uladzislau Rezki
2023-09-27 13:33 ` bhe
2023-09-27 15:25 ` Uladzislau Rezki
2023-09-22 13:41 ` Uladzislau Rezki
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=ZRLQCTh9zNIp9OH7@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=hch@infradead.org \
--cc=jaewon31.kim@samsung.com \
--cc=jason.sim@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
/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.