linux-kernel - Re: [RFC PATCH 25/26] mm: page_alloc: disallow fallbacks when 2M defrag is enabled

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: <20230421155523.p4qqx23xpwlm3yt4@techsingularity.net>
Date:   Fri, 21 Apr 2023 16:55:23 +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 25/26] mm: page_alloc: disallow fallbacks when 2M
 defrag is enabled

On Fri, Apr 21, 2023 at 11:24:48AM -0400, Johannes Weiner wrote:
> On Fri, Apr 21, 2023 at 03:56:57PM +0100, Mel Gorman wrote:
> > On Tue, Apr 18, 2023 at 03:13:12PM -0400, Johannes Weiner wrote:
> > > Fallbacks are already unlikely due to watermarks being enforced
> > > against MIGRATE_FREE blocks. Eliminate them altogether. This allows
> > > compaction to look exclusively at movable blocks, reducing the number
> > > of pageblocks it needs to scan on an ongoing basis.
> > > 
> > > Signed-off-by: Johannes Weiner <hannes@...xchg.org>
> > 
> > Conceptually this could be fun if a GFP_NOFS allocation cannot migrate
> > enough memory to free one pageblock and there are no pageblocks
> > available of the correct migratetype. Fallbacks might be unlikely but
> > never being able to fallback is a livelock risk, no?
> 
> The reserves below the watermarks are maintained in neutral
> MIGRATE_FREE blocks. So just like today, critical/limited allocation
> contexts are ensured forward progress as long as there are reserves.
> 
> An argument could be made that because smaller orders type-claim the
> entire neutral block on allocation now, the reserves can deplete
> faster than they do today given comparable watermarks. I haven't run
> into this issue during testing that would have me raise the reserves
> by a factor of NR_MIGRATETYPES. But something to keep an eye out for.

Also bear in mind low memory systems, not even the embedded ones, just
things like a cheap laptop with <= 1G. I haven't consulted the code to
think this through but forcing watermarks to be in multiples of pageblock
could be get trickier the smaller the memory size is and it would have
to be considered what happens when min_free_kbytes for a zone is smaller
than pageblock*MIGRATE_TYPES. It's possible it's protected, or could be
protected, by page_group_by_mobility_disabled but that only applies for
very small systems.

-- 
Mel Gorman
SUSE Labs