From: Michal Hocko <mhocko@suse.com>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: Hailong Liu <hailong.liu@oppo.com>,
Andrew Morton <akpm@linux-foundation.org>,
Barry Song <21cnbao@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Vlastimil Babka <vbabka@suse.cz>,
Tangquan Zheng <zhengtangquan@oppo.com>,
stable@vger.kernel.org, Baoquan He <bhe@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH v1] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0
Date: Tue, 27 Aug 2024 15:37:38 +0200 [thread overview]
Message-ID: <Zs3WouJpDk3AWV4D@tiehlicka> (raw)
In-Reply-To: <Zs3K4h5ulL1zlj6L@pc636>
On Tue 27-08-24 14:47:30, Uladzislau Rezki wrote:
> On Tue, Aug 27, 2024 at 08:49:35AM +0200, Michal Hocko wrote:
[...]
> > > 2. High-order allocations. Do you think we should not care much about
> > > it when __GFP_NOFAIL is set? Same here, there is a fallback for order-0
> > > if "high" fails, it is more likely NO_FAIL succeed for order-0. Thus
> > > keeping NOFAIL for high-order sounds like not a good approach to me.
> >
> > We should avoid high order allocations with GFP_NOFAIL at all cost.
> >
> What do you propose here? Fail such request?
We shouldn't have any hard requirements for higher order allocations in the vmalloc
right? In other words we can always fallback to base pages.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-08-27 13:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240808122019.3361-1-hailong.liu@oppo.com>
2024-08-08 21:05 ` [RESEND PATCH v1] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 Barry Song
2024-08-09 9:33 ` Michal Hocko
2024-08-09 9:41 ` Uladzislau Rezki
2024-08-16 5:07 ` Andrew Morton
2024-08-16 7:19 ` Uladzislau Rezki
2024-08-16 9:12 ` Hailong Liu
2024-08-16 10:13 ` Uladzislau Rezki
2024-08-16 11:46 ` Hailong Liu
2024-08-16 12:32 ` Michal Hocko
2024-08-23 16:42 ` Uladzislau Rezki
2024-08-26 7:52 ` Michal Hocko
2024-08-26 12:38 ` Uladzislau Rezki
2024-08-27 6:49 ` Michal Hocko
2024-08-27 12:47 ` Uladzislau Rezki
2024-08-27 13:37 ` Michal Hocko [this message]
2024-08-27 15:29 ` Uladzislau Rezki
2024-08-28 7:14 ` Michal Hocko
2024-08-28 17:23 ` Uladzislau Rezki
2024-08-19 11:59 ` Uladzislau Rezki
2024-08-19 12:57 ` Hailong Liu
2024-08-19 13:38 ` Uladzislau Rezki
2024-08-19 13:45 ` Uladzislau Rezki
2024-08-20 1:59 ` Hailong Liu
2024-08-20 6:44 ` Uladzislau Rezki
2024-08-20 6:54 ` Hailong Liu
2024-08-16 16:11 ` Baoquan He
2024-08-16 16:15 ` Baoquan He
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=Zs3WouJpDk3AWV4D@tiehlicka \
--to=mhocko@suse.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=hailong.liu@oppo.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stable@vger.kernel.org \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=zhengtangquan@oppo.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 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).