mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Torsten Kaiser" <just.for.lkml@googlemail.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org
Subject: Re: [patch] sched: fix broken smt/mc optimizations with CFS
Date: Mon, 27 Aug 2007 18:32:28 +0200	[thread overview]
Message-ID: <64bb37e0708270932h56d8744eo5ae118bdf9e8cc10@mail.gmail.com> (raw)
In-Reply-To: <20070823115416.GA31027@elte.hu>

On 8/23/07, Ingo Molnar <mingo@elte.hu> wrote:
> with no patch, or with my patch below each gets ~66% of CPU time,
> long-term:
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  2290 mingo     20   0  2736  528  252 R   67  0.0   3:22.95 bash
>  2291 mingo     20   0  2736  532  256 R   67  0.0   3:18.94 bash
>  2292 mingo     20   0  2736  532  256 R   66  0.0   3:19.83 bash
>

I just witnessed another scheduling "bug" that might have been a feature.
I use the current 2.6.23-rc3-mm1 kernel without any additional patches.

I have a 2x2218 Opteron system using the ondemand cpufreq governor,
one CPU was a max 2600 MHz, the other was at 1000 MHz.
On this system there were three processes (all niced) running, but
they all ended up at one CPU package, so that the distribution was
100-50-50 and the other CPU still idle.

So while the 100-50-50 distribution on one CPU might be fixed by your
patch, I am interested if the behavior that the second CPU remained
idle was intended.

On one hand it made perfectly sense: Even if one 50% task would be
migrated it would one get 1000MHz of CPU before the ondemand governor
kicked in, instead of 50% of 2600MHz == 1300MHZ.

A quick grep did not show me any references to cpufreq or governors in
kernel/sched* so I would expect that the scheduler can not predict
that the CPU will power up, if a task will be migrated there.

Part of my config:
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
...
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_NOTIFIERS=y
...
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
...
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set

My testcase is not reproducibly as it happened, but I could try to
recreate this, if it is necessary.

(I was running the screen saver from electricsheep.org and the three
niced tasks were three of its render threads)

Torsten

      parent reply	other threads:[~2007-08-27 16:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-16  1:01 Siddha, Suresh B
2007-08-23 10:38 ` Ingo Molnar
2007-08-23 11:54 ` Ingo Molnar
2007-08-23 12:13   ` Ingo Molnar
2007-08-23 17:42     ` Daniel Walker
2007-08-27 19:19     ` Siddha, Suresh B
2007-08-27 19:23       ` Ingo Molnar
2007-08-27 19:31         ` Siddha, Suresh B
2007-08-28 22:27           ` Siddha, Suresh B
2007-08-29  3:42             ` Ingo Molnar
2007-09-04 23:35             ` Chuck Ebbert
2007-09-04 23:46               ` Siddha, Suresh B
2007-09-05 10:51                 ` Ingo Molnar
2007-08-27 16:32   ` Torsten Kaiser [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=64bb37e0708270932h56d8744eo5ae118bdf9e8cc10@mail.gmail.com \
    --to=just.for.lkml@googlemail.com \
    --cc=akpm@linux-foundation.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

all inboxes | Powered by JetHome®