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 15:26:45 +0800 [thread overview]
Message-ID: <5243E1B5.4080409@linux.vnet.ibm.com> (raw)
In-Reply-To: <1380179397.7525.45.camel@marge.simpson.net>
On 09/26/2013 03:09 PM, Mike Galbraith wrote:
[snip]
>>
>> Ok, a double-edged sword I see :)
>>
>> May be we can wave it carefully here, give the discount to a bigger
>> scope not the sync cpu, for example:
>>
>> sg1 sg2
>> cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7
>> waker idle idle idle idle idle idle idle
>>
>> If it's sync wakeup on cpu0 (only waker), and the sg is wide enough,
>> which means one cpu is not so influencial, then suppose cpu0 to be idle
>> could be more safe, also prefer sg1 than sg2 is more likely to be right.
>>
>> And we can still choose idle-cpu at final step, like cpu1 in this case,
>> to avoid the risk that waker don't get off as it said.
>>
>> The key point is to reduce the influence of sync, trust a little but not
>> totally ;-)
>
> What we need is a dirt cheap way to fairly accurately predict overlap
> potential (todo: write omniscience().. patent, buy planet).
Agree, solutions for such cases are usually incredible ;-)
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 7:27 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
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 [this message]
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=5243E1B5.4080409@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 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.