All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: linux-kernel@vger.kernel.org, morten.rasmussen@arm.com,
	mingo@kernel.org, peterz@infradead.org,
	george.mccollister@gmail.com, ktkhai@parallels.com
Subject: Re: [PATCH RFC/TEST] sched: make sync affine wakeups work
Date: Fri, 02 May 2014 02:08:05 -0400	[thread overview]
Message-ID: <53633645.9090308@redhat.com> (raw)
In-Reply-To: <1399010337.5233.50.camel@marge.simpson.net>

On 05/02/2014 01:58 AM, Mike Galbraith wrote:
> On Fri, 2014-05-02 at 07:32 +0200, Mike Galbraith wrote: 
>> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote: 
>>> Currently sync wakeups from the wake_affine code cannot work as
>>> designed, because the task doing the sync wakeup from the target
>>> cpu will block its wakee from selecting that cpu.
>>>
>>> This is despite the fact that whether or not the wakeup is sync
>>> determines whether or not we want to do an affine wakeup...
>>
>> If the sync hint really did mean we ARE going to schedule RSN, waking
>> local would be a good thing.  It is all too often a big fat lie.
> 
> One example of that is say pgbench.  The mother of all work (server
> thread) for that load wakes with sync hint.  Let the server wake the
> first of a small herd CPU affine, and that first wakee then preempt the
> server (mother of all work) that drives the entire load.
> 
> Byebye throughput.
> 
> When there's only one wakee, and there's really not enough overlap to at
> least break even, waking CPU affine is a great idea.  Even when your
> wakees only run for a short time, if you wake/get_preempted repeat, the
> load will serialize.

I see a similar issue with specjbb2013, with 4 backend and
4 frontend JVMs on a 4 node NUMA system.

The NUMA balancing code nicely places the memory of each JVM
on one NUMA node, but then the wake_affine code will happily
run all of the threads anywhere on the system, totally ruining
memory locality.

The front end and back end only exchange a few hundred messages
a second, over loopback tcp, so the switching rate between
threads is quite low...

I wonder if it would make sense for wake_affine to be off by
default, and only switch on when the right conditions are
detected, instead of having it on by default like we have now?

I have some ideas on that, but I should probably catch some
sleep before trying to code them up :)

Meanwhile, the test patch that I posted may help us figure out
whether the "sync" option in the current wake_affine code does
anything useful.

-- 
All rights reversed

  reply	other threads:[~2014-05-02  6:08 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-02  4:42 [PATCH RFC/TEST] sched: make sync affine wakeups work Rik van Riel
2014-05-02  5:32 ` Mike Galbraith
2014-05-02  5:41   ` Mike Galbraith
2014-05-02  5:58   ` Mike Galbraith
2014-05-02  6:08     ` Rik van Riel [this message]
2014-05-02  6:36       ` Mike Galbraith
2014-05-02  6:51         ` Mike Galbraith
2014-05-02  6:13 ` Mike Galbraith
2014-05-02  6:30   ` Rik van Riel
2014-05-02  7:37     ` Mike Galbraith
2014-05-02 10:56       ` Rik van Riel
2014-05-02 11:27         ` Mike Galbraith
2014-05-02 12:51           ` Mike Galbraith
     [not found]           ` <5363B793.9010208@redhat.com>
2014-05-06 11:54             ` Peter Zijlstra
2014-05-06 20:19               ` Rik van Riel
2014-05-06 20:39                 ` Peter Zijlstra
2014-05-06 23:46                   ` Rik van Riel
2014-05-09  2:20                   ` Rik van Riel
2014-05-09  5:27                     ` [PATCH] sched: wake up task on prev_cpu if not in SD_WAKE_AFFINE domain with cpu Rik van Riel
2014-05-09  6:04                       ` [PATCH] sched: clean up select_task_rq_fair conditionals and indentation Rik van Riel
2014-05-09  7:34                       ` [PATCH] sched: wake up task on prev_cpu if not in SD_WAKE_AFFINE domain with cpu Mike Galbraith
2014-05-09 14:22                         ` Rik van Riel
2014-05-09 15:24                           ` Mike Galbraith
2014-05-09 15:24                             ` Rik van Riel
2014-05-09 17:55                               ` Mike Galbraith
2014-05-09 18:16                                 ` Rik van Riel
2014-05-10  3:54                                   ` Mike Galbraith
2014-05-13 14:08                                     ` Rik van Riel
2014-05-14  4:08                                       ` Mike Galbraith
2014-05-14 15:40                                         ` [PATCH] sched: call select_idle_sibling when not affine_sd Rik van Riel
2014-05-14 15:45                                           ` Peter Zijlstra
2014-05-19 13:08                                           ` [tip:sched/core] " tip-bot for Rik van Riel
2014-05-22 12:27                                           ` [tip:sched/core] sched: Call select_idle_sibling() " tip-bot for Rik van Riel
2014-05-04 11:44     ` [PATCH RFC/TEST] sched: make sync affine wakeups work Preeti Murthy
2014-05-04 12:04       ` Mike Galbraith
2014-05-05  4:38         ` Preeti U Murthy
2014-05-04 12:41       ` Rik van Riel
2014-05-05  4:50         ` Preeti U Murthy
2014-05-05  6:43           ` Preeti U Murthy
2014-05-05 11:28           ` Rik van Riel
2014-05-06 13:26           ` Peter Zijlstra
2014-05-06 13:25         ` Peter Zijlstra
2014-05-06 20:20           ` Rik van Riel
2014-05-06 20:41             ` Peter Zijlstra
2014-05-07 12:17               ` Ingo Molnar
2014-05-06 11:56       ` Peter Zijlstra

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=53633645.9090308@redhat.com \
    --to=riel@redhat.com \
    --cc=george.mccollister@gmail.com \
    --cc=ktkhai@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=umgwanakikbuti@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.