linux-kernel - Re: [RFC PATCH 10/26] mm: page_alloc: allow compaction capturing from larger blocks

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: <20230421141447.2cw5cfwibb7jxf6n@techsingularity.net>
Date:   Fri, 21 Apr 2023 15:14:47 +0100
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Johannes Weiner <hannes@...xchg.org>
Cc:     linux-mm@...ck.org, Kaiyang Zhao <kaiyang2@...cmu.edu>,
        Vlastimil Babka <vbabka@...e.cz>,
        David Rientjes <rientjes@...gle.com>,
        linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [RFC PATCH 10/26] mm: page_alloc: allow compaction capturing
 from larger blocks

On Tue, Apr 18, 2023 at 03:12:57PM -0400, Johannes Weiner wrote:
> Currently, capturing only works on matching orders and matching
> migratetypes. However, if capturing is initially skipped on the
> migratetype, it's possible that merging continues up to a full
> pageblock, in which case the migratetype is up for grabs again.
> 
> Allow capturing to grab smaller chunks from claimed pageblocks, and
> expand the remainder of the block back onto the freelists.
> 
> Signed-off-by: Johannes Weiner <hannes@...xchg.org>

No objections other than we're still in the preparation phase and the
series needs to be split. Out of curiousity, how often does this actually
trigger in practice? I ask because superficially, I would expect capture to
happen while pages are being merged and I'm not sure how much this actually
helps. If anything the anomaly would be merging !MOVABLE types, capturing
one pageblock and leaving the adjacent block eligible for splitting as
UNMOVABLE/RECLAIMABLE which is not necessarily desirable.

I nagged about the splitting already but ideally there would be supporting
data for all the incremental improvements before a major modification is made
to fragmentation avoidance. That way, even if the fragmentation avoidance
changes have side-effects, the incremental changes stand alone.

-- 
Mel Gorman
SUSE Labs