public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Theurer <habanero@us.ibm.com>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: kernel@kolivas.org, ricklind@us.ibm.com,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] sched: aggressive idle balance
Date: Tue, 02 Nov 2004 20:28:39 -0600	[thread overview]
Message-ID: <41884257.7000105@us.ibm.com> (raw)
In-Reply-To: <200411022230.iA2MUxq18736@unix-os.sc.intel.com>

Chen, Kenneth W wrote:

>Andrew Theurer wrote on Tuesday, November 02, 2004 12:17 PM
>  
>
>>This patch allows more aggressive idle balances, reducing idle time in
>>scenarios where should not be any, where nr_running > nr_cpus.  We have seen
>>this in a couple of online transaction workloads.  Three areas are targeted:
>>
>>1) In try_to_wake_up(), wake_idle() is called to move the task to a sibling if
>>the task->cpu is busy and the sibling is idle.  This has been expanded to any
>>idle cpu, but the closest idle cpu is picked first by starting with cpu->sd,
>>then going up the domains as necessary.
>>    
>>
>
>It occurs to me that half of the patch only applicable to HT, like the change
>in wake_idle().  And also, do you really want to put that functionality in
>wake_idle()?  Seems defeating the original intention of that function, which
>only tries to wake up sibling cpu as far as how I understand the code.
>  
>
The patch (wake_idle()) should still make a difference with nonHT 
systems.  It is true that in the mainline code, only HT systems 
benefited from wake_idle().  In fact, wake_idle() probably did nothing 
at all for Itanium, but with this patch it will, since we scan for an 
idle cpu up the domains that have flag SD_WAKE_IDLE (and we addedd that 
flag to SD_CPU_INIT and SD_NODE_INIT).

The patch's intention is to make sure we don't leave idle cpus idle.  
This can happen because the rate at which tasks are activated and 
deactivated is much higher than the idle balance interval, and because 
the task_hot prevents migrations even when we do encounter an idle 
balance tick.

Honsetly, I think you should be able to see the benefits form all 
seciotns of this patch, even without HT.

-Andrew Theurer

  reply	other threads:[~2004-11-03  2:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-02 20:16 [RFC][PATCH] sched: aggressive idle balance Andrew Theurer
2004-11-02 21:29 ` Chen, Kenneth W
2004-11-02 22:34 ` Chen, Kenneth W
2004-11-03  2:28   ` Andrew Theurer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-11-02 22:55 Chen, Kenneth W

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=41884257.7000105@us.ibm.com \
    --to=habanero@us.ibm.com \
    --cc=kenneth.w.chen@intel.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=ricklind@us.ibm.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