From: Michael wang <wangyun@linux.vnet.ibm.com>
To: Mike Galbraith <bitbucket@online.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Paul Turner <pjt@google.com>,
Rik van Riel <riel@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] sched: Avoid select_idle_sibling() for wake_affine(.sync=true)
Date: Thu, 26 Sep 2013 13:12:47 +0800 [thread overview]
Message-ID: <5243C24F.6070704@linux.vnet.ibm.com> (raw)
In-Reply-To: <1380166898.5431.40.camel@marge.simpson.net>
On 09/26/2013 11:41 AM, Mike Galbraith wrote:
[snip]
>> Like the case when we have:
>>
>> core0 sg core1 sg
>> cpu0 cpu1 cpu2 cpu3
>> waker busy idle idle
>>
>> If the sync wakeup was on cpu0, we can:
>>
>> 1. choose cpu in core1 sg like we did usually
>> some overhead but tend to make the load a little balance
>> core0 sg core1 sg
>> cpu0 cpu1 cpu2 cpu3
>> idle busy wakee idle
>
> Reducing latency and increasing throughput when the waker isn't really
> really going to immediately schedule off as the hint implies. Nice for
> bursty loads and ramp.
>
> The breakeven point is going up though. If you don't have nohz
> throttled, you eat tick start/stop overhead, and the menu governor
> recently added yet more overhead, so maybe we should say hell with it.
Exactly, more and more factors to be considered, we say things get
balanced but actually it's not the best choice...
>
>> 2. choose cpu0 like the patch proposed
>> no overhead but tend to make the load a little more unbalance
>> core0 sg core1 sg
>> cpu0 cpu1 cpu2 cpu3
>> wakee busy idle idle
>>
>> May be we should add a higher scope load balance check in wake_affine(),
>> but that means higher overhead which is just what the patch want to
>> reduce...
>
> Yeah, more overhead is the last thing we need.
>
>> What about some discount for sync case inside select_idle_sibling()?
>> For example we consider sync cpu as idle and prefer it more than the others?
>
> That's what the sync hint does. Problem is, it's a hint. If it were
> truth, there would be no point in calling select_idle_sibling().
Just wondering if the hint was wrong in most of the time, then why don't
we remove it...
Otherwise I think we can still utilize it to make some decision tends to
be correct, don't we?
Regards,
Michael Wang
>
> -Mike
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2013-09-26 5:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 7:53 [RFC][PATCH] sched: Avoid select_idle_sibling() for wake_affine(.sync=true) Peter Zijlstra
2013-09-25 8:56 ` Mike Galbraith
2013-09-26 2:50 ` Michael wang
2013-09-26 3:41 ` Mike Galbraith
2013-09-26 5:12 ` Michael wang [this message]
2013-09-26 5:34 ` Mike Galbraith
2013-09-26 6:15 ` Mike Galbraith
2013-09-26 6:32 ` Michael wang
2013-09-26 7:09 ` Mike Galbraith
2013-09-26 7:26 ` Michael wang
2013-09-26 9:58 ` Peter Zijlstra
2013-09-26 10:05 ` Peter Zijlstra
2013-09-26 10:55 ` Paul Turner
2013-09-26 11:16 ` Peter Zijlstra
2013-09-26 11:39 ` Paul Turner
2013-09-26 14:35 ` Peter Zijlstra
2013-09-26 15:43 ` Peter Zijlstra
2013-09-26 13:46 ` Mike Galbraith
2013-09-26 15:09 ` Michael wang
2013-09-26 15:44 ` Peter Zijlstra
2013-09-27 1:19 ` Michael wang
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=5243C24F.6070704@linux.vnet.ibm.com \
--to=wangyun@linux.vnet.ibm.com \
--cc=bitbucket@online.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=riel@redhat.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