linux-kernel - Re: [RFC] autonuma: Support to scan page table asynchronously

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: <20200415113226.GE20730@hirez.programming.kicks-ass.net>
Date:   Wed, 15 Apr 2020 13:32:26 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Huang Ying <ying.huang@...el.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...riel.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        Tejun Heo <tj@...nel.org>, Dave Hansen <dave.hansen@...el.com>,
        Tim Chen <tim.c.chen@...el.com>,
        Aubrey Li <aubrey.li@...el.com>
Subject: Re: [RFC] autonuma: Support to scan page table asynchronously

On Tue, Apr 14, 2020 at 01:06:46PM +0100, Mel Gorman wrote:
> While it's just an opinion, my preference would be to focus on reducing
> the cost and amount of scanning done -- particularly for threads.

This; I really don't believe in those back-charging things, esp. since
not having cgroups or having multiple applications in a single cgroup is
a valid setup.

Another way to reduce latency spikes is to decrease both
sysctl_numa_balancing_scan_delay and sysctl_numa_balancing_scan_size.
Then you do more smaller scans. By scanning more often you reduce the
contrast, by reducing the size you lower the max latency.

And this is all assuming you actually want numa balancing for this
process.