linux-kernel - Re: [PATCH 3/4] mm: Reclaim small amounts of memory when an external fragmentation event occurs

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]

Date:   Thu, 22 Nov 2018 16:22:28 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Linux-MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Rientjes <rientjes@...gle.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Zi Yan <zi.yan@...rutgers.edu>,
        Michal Hocko <mhocko@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/4] mm: Reclaim small amounts of memory when an external
 fragmentation event occurs

On Thu, Nov 22, 2018 at 04:35:58PM +0100, Vlastimil Babka wrote:
> >> I think I don't understand this comment :( Do you want to avoid waking
> >> up kswapd from steal_suitable_fallback() (introduced above) for
> >> allocations without __GFP_KSWAPD_RECLAIM? But returning 0 here means
> >> actually allowing the allocation go through steal_suitable_fallback()?
> >> So should it return ALLOC_NOFRAGMENT below, or was the intent different?
> >>
> > 
> > I want to avoid waking kswapd in steal_suitable_fallback if waking
> > kswapd is not allowed.
> 
> OK, but then this 'if' should return ALLOC_NOFRAGMENT, not 0?
> But that will still not prevent waking kswapd for nodes where there's no
> ZONE_DMA32, or any node when get_page_from_freelist() retries without
> fallback.
> 
> > If the calling context does not allow it, it does
> > mean that fragmentation will be allowed to occur. I'm banking on it
> > being a relatively rare case but potentially it'll be problematic. The
> > main source of allocation requests that I expect to hit this are THP and
> > as they are already at pageblock_order, it has limited impact from a
> > fragmentation perspective -- particularly as pageblock_order stealing is
> > allowed even with ALLOC_NOFRAGMENT.
> 
> Yep, THP will skip the wakeup in steal_suitable_fallback() via 'goto
> single_page' above it. For other users of ~__GFP_KSWAPD_RECLAIM (are
> there any?) we could maybe just ignore and wakeup kswapd anyway, since
> avoiding fragmentation is more important? Or if we wanted to avoid
> wakeup reliably, then steal_suitable_fallback() would have to know and
> check gfp_flags I'm afraid, and that doesn't seem worth the trouble.

Indeed. While it works in some cases, it'll be full of holes and while
I could close them, it just turns into a subtle mess. I've prepared a
preparation path that encodes __GFP_KSWAPD_RECLAIM in alloc_flags and checks
based on that.  It's a lot cleaner overall, it's less of a mess than passing
gfp_flags all the way through for one test and there are fewer side-effects.

Thanks!

-- 
Mel Gorman
SUSE Labs