From: Roman Gushchin <roman.gushchin@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Zhaoyang Huang <huangzhaoyang@gmail.com>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Roman Gushchin <guro@fb.com>, Minchan Kim <minchan@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
ke.wang@unisoc.com
Subject: Re: [PATCHv5] mm: optimization on page allocation when CMA enabled
Date: Mon, 9 Oct 2023 18:31:43 -0700 [thread overview]
Message-ID: <ZSSpfw_VdFkus4F5@P9FQF9L96D> (raw)
In-Reply-To: <20231009171415.cfc26b45c2f9f4489afe16c2@linux-foundation.org>
On Mon, Oct 09, 2023 at 05:14:15PM -0700, Andrew Morton wrote:
> On Sun, 8 Oct 2023 15:54:40 +0800 Zhaoyang Huang <huangzhaoyang@gmail.com> wrote:
>
> > > Roman previously asked
> > >
> > > : Also I'm a bit concerned about potential performance implications.
> > > : Would be great to provide some benchmarks or some data. Probably it's
> > > : ok because of we have pcp caches on top, but I'm not 100% sure.
> > >
> > > Are you able to perform such testing and tell us the result?
> > I have applied this patch in a v5.4 based ANDROID system and got no
> > regression problem. Actually, this commit is aimed to have
> > alloc_pages(GFP_USER) use CMA instead of stealing U&R(could lead to
> > GFP_KERNEL fail) only when zone's free pages and free cma are around
> > WATERMARK_LOW/MIN which would NOT affect most scenarios.
>
> OK, thanks.
>
> Could the appropriate people please take a look at this? It has been
> in mm-unstable since May.
I have 2 concerns:
1) it's still hard to understand the commit message and comments, I can
only reverse-engineer it based on the code changes;
2) performance concerns I expressed earlier are not addressed. Idk what's
a good benchmark for the page allocator, probably something i/o or
networking heavy.
On the positive side I believe that the patch is solving a real problem.
next prev parent reply other threads:[~2023-10-10 1:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 5:22 [PATCHv5] mm: optimization on page allocation when CMA enabled zhaoyang.huang
2023-10-06 21:17 ` Andrew Morton
2023-10-08 7:54 ` Zhaoyang Huang
2023-10-10 0:14 ` Andrew Morton
2023-10-10 1:31 ` Roman Gushchin [this message]
2023-10-10 1:42 ` Zhaoyang Huang
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=ZSSpfw_VdFkus4F5@P9FQF9L96D \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=huangzhaoyang@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=zhaoyang.huang@unisoc.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.