public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Matt Fleming <matt@codeblueprint.co.uk>
Cc: Eric Farman <farman@linux.vnet.ibm.com>,
	????????? <jinpuwang@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	"KVM-ML (kvm@vger.kernel.org)" <kvm@vger.kernel.org>,
	vcaputo@pengaru.com, Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Subject: Re: sysbench throughput degradation in 4.13+
Date: Wed, 04 Oct 2017 14:02:46 -0400	[thread overview]
Message-ID: <1507140166.10046.36.camel@redhat.com> (raw)
In-Reply-To: <20171004161850.wgnu73dokpjfyfdk@hirez.programming.kicks-ass.net>

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

On Wed, 2017-10-04 at 18:18 +0200, Peter Zijlstra wrote:
> On Tue, Oct 03, 2017 at 10:39:32AM +0200, Peter Zijlstra wrote:
> > So I was waiting for Rik, who promised to run a bunch of NUMA
> > workloads
> > over the weekend.
> > 
> > The trivial thing regresses a wee bit on the overloaded case, I've
> > not
> > yet tried to fix it.
> 
> WA_IDLE is my 'old' patch and what you all tested, WA_WEIGHT is the
> addition -- based on the old scheme -- that I've tried in order to
> lift
> the overloaded case (including hackbench).
> 
> Its not an unconditional win, but I'm tempted to default enable
> WA_WEIGHT too (I've not done NO_WA_IDLE && WA_WEIGHT runs).

Enabling both makes sense to me.

We have four cases to deal with:
- mostly idle system, in that case we don't really care,
  since select_idle_sibling will find an idle core anywhere
- partially loaded system (say 1/2 or 2/3 full), in that case
  WA_IDLE will be a great policy to help locate an idle CPU
- fully loaded system, in this case either policy works well
- overloaded system, in this case WA_WEIGHT seems to do the
  trick, assuming load balancing results in largely similar
  loads between cores inside each LLC

The big danger is affine wakeups messing up the balance
the load balancer works on, with the two mechanisms
messing up each other's placement.

However, there seems to be very little we can actually
do about that, without the unacceptable overhead of
examining the instantaneous loads on every CPU in an
LLC - otherwise we end up either overshooting, or not
taking advantage of idle CPUs, due to the use of cached
load values.

-- 
All rights reversed

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2017-10-04 18:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-12 14:14 sysbench throughput degradation in 4.13+ Eric Farman
2017-09-13  8:24 ` 王金浦
2017-09-22 15:03   ` Eric Farman
2017-09-22 15:53     ` Peter Zijlstra
2017-09-22 16:12       ` Eric Farman
2017-09-27  9:35         ` Peter Zijlstra
2017-09-27 16:27           ` Eric Farman
2017-09-28  9:08             ` Christian Borntraeger
2017-09-27 17:58           ` Rik van Riel
2017-09-28 11:04             ` Eric Farman
2017-09-28 12:36             ` Peter Zijlstra
2017-09-28 12:37             ` Peter Zijlstra
2017-10-02 22:53             ` Matt Fleming
2017-10-03  8:39               ` Peter Zijlstra
2017-10-03 16:02                 ` Rik van Riel
2017-10-04 16:18                 ` Peter Zijlstra
2017-10-04 18:02                   ` Rik van Riel [this message]
2017-10-06 10:36                   ` Matt Fleming
2017-10-10 14:51                     ` Matt Fleming
2017-10-10 15:16                       ` Peter Zijlstra
2017-10-10 17:26                         ` Ingo Molnar
2017-10-10 17:40                           ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1507140166.10046.36.camel@redhat.com \
    --to=riel@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=farman@linux.vnet.ibm.com \
    --cc=jinpuwang@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@redhat.com \
    --cc=mjrosato@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=vcaputo@pengaru.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox