linux-kernel - Re: [RFC PATCH 20/26] mm: vmscan: use compaction

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: <87o7nbe8gg.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date:   Wed, 26 Apr 2023 09:30:23 +0800
From:   "Huang, Ying" <ying.huang@...el.com>
To:     Johannes Weiner <hannes@...xchg.org>
Cc:     linux-mm@...ck.org, Kaiyang Zhao <kaiyang2@...cmu.edu>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Vlastimil Babka <vbabka@...e.cz>,
        David Rientjes <rientjes@...gle.com>,
        linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [RFC PATCH 20/26] mm: vmscan: use compaction_suitable() check
 in kswapd

Johannes Weiner <hannes@...xchg.org> writes:

> On Tue, Apr 25, 2023 at 11:12:28AM +0800, Huang, Ying wrote:
>> Johannes Weiner <hannes@...xchg.org> writes:
>> 
>> > Kswapd currently bails on higher-order allocations with an open-coded
>> > check for whether it's reclaimed the compaction gap.
>> >
>> > compaction_suitable() is the customary interface to coordinate reclaim
>> > with compaction.
>> >
>> > Signed-off-by: Johannes Weiner <hannes@...xchg.org>
>> > ---
>> >  mm/vmscan.c | 67 ++++++++++++++++++-----------------------------------
>> >  1 file changed, 23 insertions(+), 44 deletions(-)
>> >
>> > diff --git a/mm/vmscan.c b/mm/vmscan.c
>> > index ee8c8ca2e7b5..723705b9e4d9 100644
>> > --- a/mm/vmscan.c
>> > +++ b/mm/vmscan.c
>> > @@ -6872,12 +6872,18 @@ static bool pgdat_balanced(pg_data_t *pgdat, int order, int highest_zoneidx)
>> >  		if (!managed_zone(zone))
>> >  			continue;
>> >  
>> > +		/* Allocation can succeed in any zone, done */
>> >  		if (sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING)
>> >  			mark = wmark_pages(zone, WMARK_PROMO);
>> >  		else
>> >  			mark = high_wmark_pages(zone);
>> >  		if (zone_watermark_ok_safe(zone, order, mark, highest_zoneidx))
>> >  			return true;
>> > +
>> > +		/* Allocation can't succeed, but enough order-0 to compact */
>> > +		if (compaction_suitable(zone, order,
>> > +					highest_zoneidx) == COMPACT_CONTINUE)
>> > +			return true;
>> 
>> Should we check the following first?
>> 
>>         order > 0 && zone_watermark_ok_safe(zone, 0, mark, highest_zoneidx)
>
> That's what compaction_suitable() does. It checks whether there are
> enough migration targets for compaction (COMPACT_CONTINUE) or whether
> reclaim needs to do some more work (COMPACT_SKIPPED).

Yes.  And I found that the watermark used in compaction_suitable() is
low_wmark_pages() or min_wmark_pages(), which doesn't match the
watermark here.  Or did I miss something?

Best Regards,
Huang, Ying