linux-kernel - Re: [Resend] Possible bug in __fragmentation

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] [day] [month] [year] [list]

Message-Id: <AA7930B9-1E4D-400C-89EA-FC2FC6A7E1E4@oracle.com>
Date:   Fri, 9 Feb 2018 14:43:50 +0000
From:   Robert Harris <robert.m.harris@...cle.com>
To:     Mel Gorman <mgorman@...e.de>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...nel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Kemi Wang <kemi.wang@...el.com>, ying.huang@...el.com,
        David Rientjes <rientjes@...gle.com>,
        Vinayak Menon <vinmenon@...eaurora.org>
Subject: Re: [Resend] Possible bug in __fragmentation_index()

On 2 Feb 2018, at 17:47, Mel Gorman wrote:

> On Fri, Feb 02, 2018 at 02:16:39PM +0000, Robert Harris wrote:
>> I was planning to annotate the opaque calculation in
>> __fragmentation_index() but on closer inspection I think there may be a
>> bug.  I could use some feedback.

A belated thank you for the reply.

> It's intentional but could be fixed to give a real bound of 0 to 1 instead
> of half the range as it currently give. The sysctl_extfrag_threshold should
> also be adjusted at that time. After that, the real work is determining
> if it's safe to strike a balance between reclaim/compaction that avoids
> unnecessary compaction while not being too aggressive about reclaim or
> having kswapd enter a runaway loop with a reintroduction of the "kswapd
> stuck at 100% CPU time" problems.

In my (incomplete) view, striking the balance is a case of determining the
cost of memory regeneration through compaction versus reclaim and choosing
the cheaper.  I'm reasonably confident that this could be achieved for
compaction, which is why the calculation in __fragmentation_index() caught
my eye in the first place, but reclaim/swapping is probably significantly
harder to quantify.  Similarly, a cost function for allocation failure
is also necessary but not obvious.

All of the above is just a nebulous plan for now;  in the meantime, I'll
change __fragmentation_index() and the threshold as you suggest.

Robert  Harris