Received-SPF: pass (google.com: domain of linux-kernel+bounces-20073-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <ca270573-5527-6df0-3fed-17e8c54b4f89@quicinc.com>
Date: Mon, 8 Jan 2024 12:15:05 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH] mm,page_alloc,cma: configurable CMA utilization
Content-Language: en-US
To: Roman Gushchin <roman.gushchin@linux.dev>
CC: Minchan Kim <minchan@kernel.org>,
        Chris Goldsworthy
	<quic_cgoldswo@quicinc.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Rik
 van Riel" <riel@surriel.com>, Roman Gushchin <guro@fb.com>,
        Vlastimil Babka
	<vbabka@suse.cz>, Joonsoo Kim <js1304@gmail.com>,
        Georgi Djakov
	<quic_c_gdjako@quicinc.com>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>
References: <20230131071052.GB19285@hu-sbhattip-lv.qualcomm.com>
 <Y9lZoI89Nw4bjjOZ@P9FQF9L96D.corp.robot.car>
 <20230131201001.GA8585@hu-sbhattip-lv.qualcomm.com>
 <Y9mraBHucYdnHXiS@P9FQF9L96D.corp.robot.car>
 <20230201040628.GA3767@hu-cgoldswo-sd.qualcomm.com>
 <Y9r6LtMOPHfxr7UL@google.com>
 <b9b5b669-0318-93c8-c6a0-dbbb797320f2@quicinc.com>
 <ZZiZVnJpOpt1DAq1@P9FQF9L96D.corp.robot.car>
From: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
In-Reply-To: <ZZiZVnJpOpt1DAq1@P9FQF9L96D.corp.robot.car>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit


On 1/5/2024 4:05 PM, Roman Gushchin wrote:
> I'm not sure there is a "one size fits all" solution here. 
agree - that's why we are thinking a configurable cma utilization would be
useful.
> There are two distinctive cases:
> 1) A relatively small cma area used for a specific purpose. This is how cma
>    was used until recently. And it was barely used by the kernel for non-cma
>    allocations.
> 2) A relatively large cma area which is used to allocate gigantic hugepages
>    and as an anti-fragmentation mechanism in general (basically as a movable
>    zone). In this case it might be preferable to use cma for movable
>    allocations, because the space for non-movable allocations might be limited.
>
> I see two options here:
> 1) introduce per-cma area flags which will define the usage policy
Could you please elaborate on this - how would we use the per-cma flags
when allocating pages?
> 2) redesign the page allocator to better take care of fragmentation at 1Gb scale
>
> The latter is obviously not a small endeavour.
> The fundamentally missing piece is a notion of an anti-fragmentation cost.
> E.g. how much work does it makes sense to put into page migration
> before "polluting" a new large block of memory with an unmovable folio.

Stepping back, we are trying to solve for a situation where system:
        - has lot of movable allocs in zone normal
        - has lot of idle memory in CMA region
        - but is low on memory for unmovable allocs, leading to oom-kills

On devices where cma region is mostly idle, allocating movable pages from
the cma region would have lesser overhead?

IIUC, this redesign for smarter migration would be in addition to or in
parallel to the CMA utilization right?

Thanks,

Sukadev


>
> Thanks!