All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Andrew Morton <akpm@osdl.org>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	npiggin@suse.de, Ingo Molnar <mingo@elte.hu>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Con Kolivas <kernel@kolivas.org>
Subject: Re: [PATCH] Fix smpnice high priority task hopping problem
Date: Fri, 17 Feb 2006 13:51:46 +1100	[thread overview]
Message-ID: <43F53A42.2090909@bigpond.net.au> (raw)
In-Reply-To: <43F53553.50904@bigpond.net.au>

Peter Williams wrote:
> Siddha, Suresh B wrote:
> 
>> Andrew, Please don't apply this patch. This breaks the existing HT
>> (and multi-core) scheduler optimizations.
>>
>> Peter, on a DP system with HT, if we have only two runnable processes
>> and they end up running on the two threads of the same package, with 
>> your patch, migration thread will never move one of those processes to 
>> the idle package..
> 
> 
> On a normal system, would either of them be moved anyway?
> 
>>
>> To fix my reported problem, we need to make sure that 
>> find_busiest_group()
>> doesn't find an imbalance..
> 
> 
> I disagree.  If this causes a problem with your "optimizations" then I 
> think that you need to fix the "optimizations".
> 
> There's a rational argument (IMHO) that this patch should be applied 
> even in the absence of the smpnice patches as it prevents 
> active_load_balance() doing unnecessary work.  If this isn't good for 
> hypo threading then hypo threading is a special case and needs to handle 
> it as such.

OK.  The good news is that (my testing shows that) the "sched: fix 
smpnice abnormal nice anomalies" fixes the imbalance problem and the 
consequent CPU hopping.

BUT I still think that this patch (modified if necessary to handle any 
HT special cases) should be applied.  On a normal system, it will (as 
I've already said) stop active_load_balance() from doing a lot of 
unnecessary work INCLUDING holding the run queue locks for TWO run 
queues for no good reason.

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

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

  reply	other threads:[~2006-02-17  2:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-16  0:39 [PATCH] Fix smpnice high priority task hopping problem Peter Williams
2006-02-17  1:13 ` Siddha, Suresh B
2006-02-17  2:30   ` Peter Williams
2006-02-17  2:51     ` Peter Williams [this message]
2006-02-17  2:58       ` Siddha, Suresh B
2006-02-17  3:16         ` Peter Williams
2006-02-17  2:54     ` Siddha, Suresh B
2006-02-17  3:14       ` Peter Williams

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=43F53A42.2090909@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=rostedt@goodmis.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=torvalds@osdl.org \
    /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.