public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: Andrew Morton <akpm@osdl.org>, Mike Galbraith <efault@gmx.de>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Ingo Molnar <mingo@elte.hu>, Con Kolivas <kernel@kolivas.org>,
	"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: smpnice work around for active_load_balance()
Date: Tue, 04 Apr 2006 09:11:53 +1000	[thread overview]
Message-ID: <4431ABB9.6050708@bigpond.net.au> (raw)
In-Reply-To: <20060403095747.A29737@unix-os.sc.intel.com>

Siddha, Suresh B wrote:
> On Mon, Apr 03, 2006 at 11:04:52AM +1000, Peter Williams wrote:
>> Peter Williams wrote:
>>> I gave an example in a previous e-mail.  Basically, at the end of 
>>> scheduler_tick() if rebalance_tick() doesn't move any tasks (it would be 
>>> foolish to contemplate moving tasks of the queue just after you've moved 
>>> some there) and the run queue has exactly one running task and it's time 
>>> for a HT/MC rebalance check on the package that this run queue belongs 
>>> to then check that package to to see if it meets the rest of criteria 
>>> for needing to lose some tasks.  If it does look for a package that is a 
>>> suitable recipient for the moved task and if you find one then mark this 
>>> run queue as needing active load balancing and arrange for its migration 
>>> thread to be started.
>>>
>>> Simple, direct and amenable to being only built on architectures that 
>>> need the functionality.
>> Are you working on this idea or should I do it?
> 
> my issues raised in response to this idea are unanswered.
> 
> <issues>
> First of all we will be doing unnecessary checks to see if there is
> an imbalance..

There will be saved overhead when the current code is removed that can 
be used.  Also, if you examine the idea you'll find that it would be 
very cheap and the possibilities for early abandonment of the checks 
would make them very efficient.

> Current code triggers the checks and movement only when
> it is necessary..

That is untrue.  The best you can say is when they MIGHT be necessary.

> And second, finding the correct destination cpu in the 
> presence of SMT and MC is really complicated.. Look at different examples
> in the OLS paper.. Domain topology provides all this info with no added
> complexity...

This to me would seem to be an argument in favour of change rather than 
an argument for retaining the current highly random process.

Finding the appropriate destination package/queue can be left to 
active_load_balance() and this would reduce the impact of the inherent 
raciness of load balancing.

> </issues>
> 
> I don't see a merit and so I am not looking into this.

OK.  I'll do it.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

      reply	other threads:[~2006-04-03 23:11 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-28  6:00 [PATCH] sched: smpnice work around for active_load_balance() Peter Williams
2006-03-28 19:25 ` Siddha, Suresh B
2006-03-28 22:44   ` Peter Williams
2006-03-29  2:14     ` Peter Williams
2006-03-29  2:52     ` Siddha, Suresh B
2006-03-29  3:42       ` Peter Williams
2006-03-29 22:52         ` Siddha, Suresh B
2006-03-29 23:40           ` Peter Williams
2006-03-30  0:50             ` Siddha, Suresh B
2006-03-30  1:14               ` Peter Williams
2006-04-02  4:48                 ` smpnice loadbalancing with high priority tasks Siddha, Suresh B
2006-04-02  7:08                   ` Peter Williams
2006-04-04  0:24                     ` Siddha, Suresh B
2006-04-04  1:22                       ` Peter Williams
2006-04-04  1:34                         ` Peter Williams
2006-04-04  2:11                         ` Siddha, Suresh B
2006-04-04  3:24                           ` Peter Williams
2006-04-04  4:34                             ` Peter Williams
2006-04-06  2:14                             ` Peter Williams
2006-04-20  1:24                     ` [patch] smpnice: don't consider sched groups which are lightly loaded for balancing Siddha, Suresh B
2006-04-20  5:19                       ` Peter Williams
2006-04-20 16:54                         ` Siddha, Suresh B
2006-04-20 23:11                           ` Peter Williams
2006-04-20 23:49                           ` Andrew Morton
2006-04-21  0:25                             ` Siddha, Suresh B
2006-04-21  0:28                             ` Peter Williams
2006-04-21  1:25                               ` Andrew Morton
2006-04-20 17:04                         ` Siddha, Suresh B
2006-04-21  0:00                           ` Peter Williams
2006-04-03  1:04             ` [PATCH] sched: smpnice work around for active_load_balance() Peter Williams
2006-04-03 16:57               ` Siddha, Suresh B
2006-04-03 23:11                 ` Peter Williams [this message]

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=4431ABB9.6050708@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=efault@gmx.de \
    --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=suresh.b.siddha@intel.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