From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Andrew Morton <akpm@osdl.org>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
kernel@kolivas.org, npiggin@suse.de, mingo@elte.hu,
rostedt@goodmis.org, linux-kernel@vger.kernel.org,
torvalds@osdl.org
Subject: Re: [rfc][patch] sched: remove smpnice
Date: Tue, 14 Feb 2006 01:07:12 -0800 [thread overview]
Message-ID: <20060214010712.B20191@unix-os.sc.intel.com> (raw)
In-Reply-To: <43ED3D6A.8010300@bigpond.net.au>; from pwil3058@bigpond.net.au on Fri, Feb 10, 2006 at 05:27:06PM -0800
On Fri, Feb 10, 2006 at 05:27:06PM -0800, Peter Williams wrote:
>> "Siddha, Suresh B" <suresh.b.siddha@intel.com> wrote:
>>>My testing showed that 178.galgel in SPECfp2000 is down by
>~10% when run with
>>>nice -20 on a 4P(8-way with HT) system compared to a nice-0 run.
>
>Is it normal to run enough -20 tasks to cause this problem to manifest?
On a 4P(8-way with HT), if you run a -20 task(a simple infinite loop)
it hops from one processor to another processor... you can observe it
using top.
find_busiest_group() thinks there is an imbalance and ultimately the
idle cpu kicks active load balance on busy cpu, resulting in the hopping.
>>>
>>>b) On a lightly loaded system, this can result in HT
>scheduler optimizations
>>>being disabled in presence of low priority tasks... in this
>case, they(low
>>>priority ones) can end up running on the same package, even
>in the presence
>>>of other idle packages.. Though this is not as serious as
>"a" above...
>>>
>
>I think that this issue comes under the heading of "Result of better
>nice enforcement" which is the purpose of the patch :-). I wouldn't
>call this HT disablement or do I misunderstand the issue.
>
>The only way that I can see load balancing subverting the HT
>scheduling
>mechanisms is if (say) there are 2 CPUs with 2 HT channels
>each and all
>of the high priority tasks end up sharing the 2 channels of one CPU
>while all of the low priority tasks share the 2 channels of the other
>one. This scenario is far more likely to happen without the smpnice
>patches than with them.
I agree with you.. But lets take a DP system with HT, now if there are
only two low priority tasks running, ideally we should be running them
on two different packages. With this patch, we may end up running on the
same logical processor.. leave alone running on the same package..
As these are low priority tasks, it might be ok.. But...
thanks,
suresh
next prev parent reply other threads:[~2006-02-14 9:07 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-07 14:28 [rfc][patch] sched: remove smpnice Nick Piggin
2006-02-07 14:57 ` Con Kolivas
2006-02-07 15:05 ` Nick Piggin
2006-02-07 22:15 ` Andrew Morton
2006-02-07 23:11 ` Con Kolivas
2006-02-07 23:36 ` Andrew Morton
2006-02-08 3:28 ` Nick Piggin
2006-02-08 14:56 ` Ingo Molnar
2006-02-10 7:01 ` Siddha, Suresh B
2006-02-10 7:17 ` Andrew Morton
2006-02-10 7:23 ` Con Kolivas
2006-02-10 9:06 ` Ingo Molnar
2006-02-11 1:27 ` Peter Williams
2006-02-11 2:00 ` Andrew Morton
2006-02-12 1:13 ` Peter Williams
2006-02-12 23:10 ` Peter Williams
2006-02-13 1:06 ` Peter Williams
2006-02-14 0:37 ` Peter Williams
2006-02-14 8:53 ` Siddha, Suresh B
2006-02-11 3:36 ` Peter Williams
2006-02-11 4:04 ` Peter Williams
2006-02-14 9:07 ` Siddha, Suresh B [this message]
2006-02-14 22:40 ` Peter Williams
2006-02-14 23:44 ` Paul Jackson
2006-02-15 0:09 ` Peter Williams
2006-02-15 1:00 ` Paul Jackson
2006-02-15 7:07 ` Siddha, Suresh B
2006-02-15 22:36 ` Peter Williams
2006-02-15 23:29 ` Peter Williams
2006-02-13 14:12 ` Con Kolivas
2006-02-07 23:20 ` Peter Williams
2006-02-07 23:29 ` Con Kolivas
2006-02-07 23:36 ` Martin Bligh
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=20060214010712.B20191@unix-os.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--cc=akpm@osdl.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=pwil3058@bigpond.net.au \
--cc=rostedt@goodmis.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox