| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAGWkznG5V+=onj9TsEhwh=Pxqt9+-KJAHLAoLJRMQ5-ysnwDgQ@mail.gmail.com>
Date: Thu, 4 May 2023 14:23:01 +0800
From: Zhaoyang Huang <huangzhaoyang@...il.com>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: 黄朝阳 (Zhaoyang Huang)
<zhaoyang.huang@...soc.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <guro@...com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
王科 (Ke Wang) <Ke.Wang@...soc.com>,
"fangzheng.zhang@...soc.com" <fangzheng.zhang@...soc.com>
Subject: Re: 答复: [PATCH] mm: optimization on page allocation when CMA enabled
On Thu, May 4, 2023 at 12:30 AM Roman Gushchin <roman.gushchin@...ux.dev> wrote:
>
> On Wed, May 03, 2023 at 03:58:21PM +0800, Zhaoyang Huang wrote:
> > On Wed, May 3, 2023 at 6:01 AM Roman Gushchin <roman.gushchin@...ux.dev> wrote:
> > >
> > > On Tue, May 02, 2023 at 12:12:28PM +0000, 黄朝阳 (Zhaoyang Huang) wrote:
> > > > > Hi Zhaoyang!
> > > > >
> > > > > On Fri, Apr 28, 2023 at 07:00:41PM +0800, zhaoyang.huang wrote:
> > > > > > From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> > > > > >
> > > > > > Please be notice bellowing typical scenario that commit 168676649
> > > > > > introduce, that is, 12MB free cma pages 'help' GFP_MOVABLE to keep
> > > > > > draining/fragmenting U&R page blocks until they shrink to 12MB without
> > > > > > enter slowpath which against current reclaiming policy. This commit change
> > > > > the criteria from hard coded '1/2'
> > > > > > to watermark check which leave U&R free pages stay around WMARK_LOW
> > > > > > when being fallback.
> > > > >
> > > > > Can you, please, explain the problem you're solving in more details?
> > > > I am trying to solve a OOM problem caused by slab allocation fail as all free pages are MIGRATE_CMA by applying 168676649, which could help to reduce the fault ration from 12/20 to 2/20. I noticed it introduce the phenomenon which I describe above.
> > > > >
> > > > > If I understand your code correctly, you're effectively reducing the use of cma
> > > > > areas for movable allocations. Why it's good?
> > > > Not exactly. In fact, this commit lead to the use of cma early than it is now, which could help to protect U&R be 'stolen' by GFP_MOVABLE. Imagine this scenario, 30MB total free pages composed of 10MB CMA and 20MB U&R, while zone's watermark low is 25MB. An GFP_MOVABLE allocation can keep stealing U&R pages(don't meet 1/2 criteria) without enter slowpath(zone_watermark_ok(WMARK_LOW) is true) until they shrink to 15MB. In my opinion, it makes more sense to have CMA take its duty to help movable allocation when U&R lower to certain zone's watermark instead of when their size become smaller than CMA.
> > > > > Also, this is a hot path, please, make sure you're not adding much overhead.
> > > > I would like to take more thought.
> > >
> > > Got it, thank you for the explanation!
> > >
> > > How about the following approach (completely untested)?
> > >
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 6da423ec356f..4b50f497c09d 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -2279,12 +2279,13 @@ __rmqueue(struct zone *zone, unsigned int order, int migratetype,
> > > if (IS_ENABLED(CONFIG_CMA)) {
> > > /*
> > > * Balance movable allocations between regular and CMA areas by
> > > - * allocating from CMA when over half of the zone's free memory
> > > - * is in the CMA area.
> > > + * allocating from CMA when over half of the zone's easily
> > > + * available free memory is in the CMA area.
> > > */
> > > if (alloc_flags & ALLOC_CMA &&
> > > zone_page_state(zone, NR_FREE_CMA_PAGES) >
> > > - zone_page_state(zone, NR_FREE_PAGES) / 2) {
> > > + (zone_page_state(zone, NR_FREE_PAGES) -
> > > + zone->_watermark[WMARK_LOW]) / 2) {
> > IMO, we should focus on non-cma area which trigger use of cma when
> > they are lower than corresponding watermark(there is still
> > WMARK_MIN/HIGH to deal with within slowpath)
> > > page = __rmqueue_cma_fallback(zone, order);
> > > if (page)
> > > return page;
> > >
> > > Basically the idea is to keep free space equally split between cma and non-cma areas.
> > > Will it work for you?
> > I don't think it makes sense to 'equally split' cma and non-cma areas
> > over free space while cma could occupy various proportions in a single
> > zone. This fixed 1/2 could lead to different situation on 20% or 50%
> > cma occupation.
>
> Can you then, please, explain in details what you're proposing instead
> and why it's better (not only in your case, but generally as well)?
> For the context, my original usecase was cma size under 10G and
> the total memory size between 32G and 128G.
Let us look at the series of scenarios below with
WMARK_LOW=25MB,WMARK_MIN=5MB(managed pages 1.9GB). We can know that
1. optimized 1/2 method start to use CMA since D which actually has
caused U&R lower than WMARK_LOW (this could be deemed as against
current memory policy, that is, U&R should either keeping stay around
WATERMARK_LOW or enter slowpath to do reclaiming)
2. it keep using CMA as long as free pages keep shrinking (this is
against the original desire of balance cma & none-cma area)
free_cma/free_pages(MB) A(12/30) B(10/25) C(8/25)
D(8/20) E(8/16) F(5/12) F(5/10) G(4/8)
optimized 1/2 N N
N Y Y Y
Y Y
!zone_watermark_ok Y Y
Y N N N Y
Y
>
> Looking at your original patch, I see that __if_use_cma_first() always returns
> false if zone_watermark_ok() returns true. It worries me.
ok. we could deal with the scenario here when free pages is higher
than WMARK_HIGH
>
> Thanks!
Powered by blists - more mailing lists