linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Wang <wangyun@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Mike Galbraith <efault@gmx.de>,
	Namhyung Kim <namhyung@kernel.org>, Alex Shi <alex.shi@intel.com>,
	Paul Turner <pjt@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
	Ram Pai <linuxram@us.ibm.com>
Subject: Re: [PATCH] sched: wakeup buddy
Date: Tue, 12 Mar 2013 11:23:50 +0800	[thread overview]
Message-ID: <513E9FC6.4060507@linux.vnet.ibm.com> (raw)
In-Reply-To: <1362998219.14933.9.camel@laptop>

On 03/11/2013 06:36 PM, Peter Zijlstra wrote:
> On Fri, 2013-03-08 at 10:50 +0800, Michael Wang wrote:
> 
>>> OK, so there's two issues I have with all this are:
>>>
>>>  - it completely wrecks task placement for things like interrupts (sadly I don't
>>>      have a good idea about a benchmark where this matters).
>>
>> I don't get this point...could you please give more details?
> 
> Take for instance a network workload, the hardirq notifies us there's
> data buffered, then softirq does a ton of network layer demuxing and
> eventually wakes one (or more) tasks to process data. You want these
> tasks to move to the waking cpu, it has lots of this data in cache.
> 
> Now, neither hard- nor softirq runs in task context (except for -rt) so
> it completely fails on what you propose.

I got it, exactly, the new feature with current ref limit will miss this
optimize timing, if the data not related to current...

However, we are still gambling here, and some workload suffered.

Actually this feature's purpose is to provide a way for user who want to
balance the risk and benefit on self demand, it providing flexible, not
restriction...

So what about make the default sysctl_sched_wakeup_buddy_ref to be 0 and
make every thing just like the old world.

And for those who want to make the decision more carefully, they could
turn the knob to make it bigger, and gain the benefit.

> 
> We could simply add something like in_softirq() || in_irq() etc.. to
> re-enable wake_affine() for those cases unconditionally, but not sure
> that's the right thing either.
> 
>>>  - yet another random number.. :/
>>
>> Correct...well, but that also means flexibility, I suppose different
>> system and workload will need some tuning on this knob to gain more
>> benefit, by default, they will gain some benefit, small or big.
> 
> Nah, it just means another knob nobody knows how to twiddle.

Right, and we already have many such kind of knob...since some formular
is impossible to be written down.

Mysterious knob, I twiddle it and wait for something to drop from sky,
candy, cake or rock, whatever, there are adventures there ;-)

And I believe if once the cake drop from sky, there will be more
adventurers, and it won't be a mysterious knob any more.

> 
>>> Also, I'm starting to dislike the buddy name; its somewhat over-used.
>>
>> I have to agree :), any suggestions?
> 
> Nah.. I suppose it depends a bit on the shape the final solution takes,

What about default sysctl_sched_wakeup_buddy_ref = 0 and keep the old
logical?

Regards,
Michael Wang


> but I'll think about it.
> 
> --
> 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/
> 


  reply	other threads:[~2013-03-12  3:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06  7:06 [PATCH] sched: wakeup buddy Michael Wang
2013-03-07  8:36 ` Peter Zijlstra
2013-03-07  9:43   ` Mike Galbraith
2013-03-08  2:37     ` Michael Wang
2013-03-08  6:44       ` Mike Galbraith
2013-03-08  7:30         ` Michael Wang
2013-03-08  8:26           ` Mike Galbraith
2013-03-11  2:42             ` Michael Wang
2013-03-07  9:46   ` Michael Wang
2013-03-07 16:52     ` Peter Zijlstra
2013-03-08  2:31       ` Michael Wang
2013-03-11  8:21   ` Ingo Molnar
2013-03-11  9:14     ` Michael Wang
2013-03-11  9:40       ` Ingo Molnar
2013-03-12  6:00         ` Michael Wang
2013-03-12  8:48           ` Ingo Molnar
2013-03-12  9:41             ` Michael Wang
2013-03-07 17:21 ` Peter Zijlstra
2013-03-08  2:33   ` Michael Wang
2013-03-07 17:27 ` Peter Zijlstra
2013-03-08  2:50   ` Michael Wang
2013-03-11 10:36     ` Peter Zijlstra
2013-03-12  3:23       ` Michael Wang [this message]
2013-03-12 10:08         ` Peter Zijlstra
2013-03-13  3:07           ` Michael Wang
2013-03-14 10:58             ` Peter Zijlstra
2013-03-15  6:24               ` Michael Wang
2013-03-18  3:26                 ` 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=513E9FC6.4060507@linux.vnet.ibm.com \
    --to=wangyun@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@intel.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=pjt@google.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;
as well as URLs for NNTP newsgroup(s).