linux-kernel - Re: [PATCH] mm,page_alloc,cma: configurable CMA utilization

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ca270573-5527-6df0-3fed-17e8c54b4f89@quicinc.com>
Date: Mon, 8 Jan 2024 12:15:05 -0800
From: Sukadev Bhattiprolu <quic_sukadev@...cinc.com>
To: Roman Gushchin <roman.gushchin@...ux.dev>
CC: Minchan Kim <minchan@...nel.org>,
        Chris Goldsworthy
	<quic_cgoldswo@...cinc.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Rik
 van Riel" <riel@...riel.com>, Roman Gushchin <guro@...com>,
        Vlastimil Babka
	<vbabka@...e.cz>, Joonsoo Kim <js1304@...il.com>,
        Georgi Djakov
	<quic_c_gdjako@...cinc.com>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm,page_alloc,cma: configurable CMA utilization


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!