[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o8rsxlws.fsf@yhuang-dev.intel.com>
Date: Thu, 16 Apr 2020 09:24:35 +0800
From: "Huang\, Ying" <ying.huang@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Mel Gorman <mgorman@...hsingularity.net>, <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
Peter Zijlstra <peterz@...radead.org> writes:
> 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.
Technically, it appears possible to back-charge the CPU time to the
process/thread directly (not the cgroup).
> 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.
Yes. This can reduce latency spikes.
Best Regards,
Huang, Ying
> And this is all assuming you actually want numa balancing for this
> process.
Powered by blists - more mailing lists