Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: w9j0dUKdfsEKejz45edleyYO38s8QjFEePL/HDTvmi4Pgb9ozgi1HDEJDXBuIKPQmuIo/kCN8f
 9PKPchy1Mfeg==
IronPort-SDR: AQnTsEyPjDfJLfBwR7ukTNUMbQA3doOQTB0AHlDuA7/jyWZTsHuqs3lNIONfA+48WF41fzdUgG
 eY/ZdXU7NVuA==
From:   "Huang\, Ying" <ying.huang@intel.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Mel Gorman <mgorman@techsingularity.net>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
        Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@surriel.com>,
        Daniel Jordan <daniel.m.jordan@oracle.com>,
        Tejun Heo <tj@kernel.org>, Dave Hansen <dave.hansen@intel.com>,
        Tim Chen <tim.c.chen@intel.com>,
        Aubrey Li <aubrey.li@intel.com>
Subject: Re: [RFC] autonuma: Support to scan page table asynchronously
References: <20200414081951.297676-1-ying.huang@intel.com>
        <20200414120646.GN3818@techsingularity.net>
        <20200415113226.GE20730@hirez.programming.kicks-ass.net>
Date:   Thu, 16 Apr 2020 09:24:35 +0800
In-Reply-To: <20200415113226.GE20730@hirez.programming.kicks-ass.net> (Peter
        Zijlstra's message of "Wed, 15 Apr 2020 13:32:26 +0200")
Message-ID: <87o8rsxlws.fsf@yhuang-dev.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Peter Zijlstra <peterz@infradead.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.