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: <20230425154026.GC17132@cmpxchg.org>
Date:   Tue, 25 Apr 2023 11:40:26 -0400
From:   Johannes Weiner <hannes@...xchg.org>
To:     Mel Gorman <mgorman@...hsingularity.net>
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 Fri, Apr 21, 2023 at 03:14:47PM +0100, Mel Gorman wrote:
> 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.

Looking at this patch independently, once merging continues to the
full block, a fallback would be allowed to claim it anyway
(can_steal_fallback() returns true). I don't quite see a downside
letting capture apply in this case. The plus is of course avoiding the
indirection through the freelist which risks an opportunist request of
a smaller order fragmenting the block and wasting the contiguity work.

In the context of the full series, this becomes even more
important. Once watermarks are required to be met in MIGRATE_FREE
blocks, and reclaim/compaction recycle full blocks, merging up to
pageblock_order happens all the time - and needs to happen for
allocations to succeed. This applies to all types of direct reclaim:
unmovable request freeing reclaimable/movable blocks, reclaimable
freeing movable blocks, movable freeing reclaimable blocks.

I see your point about smaller orders now always ending the merge at
the pageblock, even when there could be additional merging
opportunities beyond. However, I'm not sure these accidental larger
merges beyond what's needed to fulfill the request at hand are a
preferable aspect over reclaimer fairness, and thus ultimately the
reliability of orders up to the pageblock size.

I'll try to get some numbers for this patch independently, though.
This should manifest in p99 allocation latencies and near-OOM
behavior. Is there anything else you'd want me to look for?

Thanks!