[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200508092212.GE3758@techsingularity.net>
Date: Fri, 8 May 2020 10:22:12 +0100
From: Mel Gorman <mgorman@...hsingularity.net>
To: Jirka Hladky <jhladky@...hat.com>
Cc: Phil Auld <pauld@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Juri Lelli <juri.lelli@...hat.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>,
Valentin Schneider <valentin.schneider@....com>,
Hillf Danton <hdanton@...a.com>,
LKML <linux-kernel@...r.kernel.org>,
Douglas Shakshober <dshaks@...hat.com>,
Waiman Long <longman@...hat.com>,
Joe Mario <jmario@...hat.com>, Bill Gray <bgray@...hat.com>
Subject: Re: [PATCH 00/13] Reconcile NUMA balancing decisions with the load
balancer v6
On Thu, May 07, 2020 at 06:29:44PM +0200, Jirka Hladky wrote:
> Hi Mel,
>
> we are not targeting just OMP applications. We see the performance
> degradation also for other workloads, like SPECjbb2005 and
> SPECjvm2008. Even worse, it also affects a higher number of threads.
> For example, comparing 5.7.0-0.rc2 against 5.6 kernel, on 4 NUMA
> server with 2x AMD 7351 CPU, we see performance degradation 22% for 32
> threads (the system has 64 CPUs in total). We observe this degradation
> only when we run a single SPECjbb binary. When running 4 SPECjbb
> binaries in parallel, there is no change in performance between 5.6
> and 5.7.
>
Minimally I suggest confirming that it's really due to
adjust_numa_imbalance() by making the function a no-op and retesting.
I have found odd artifacts with it but I'm unsure how to proceed without
causing problems elsehwere.
For example, netperf on localhost in some cases reported a regression
when the client and server were running on the same node. The problem
appears to be that netserver completes its work faster when running
local and goes idle more regularly. The cost of going idle and waking up
builds up and a lower throughput is reported but I'm not sure if gaming
an artifact like that is a good idea.
> That's why we are asking for the kernel tunable, which we would add to
> the tuned profile. We don't expect users to change this frequently but
> rather to set the performance profile once based on the purpose of the
> server.
>
> If you could prepare a patch for us, we would be more than happy to
> test it extensively. Based on the results, we can then evaluate if
> it's the way to go. Thoughts?
>
I would suggest simply disabling that function first to ensure that is
really what is causing problems for you.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists