linux-kernel - Re: [patch] sched: fix broken smt/mc optimizations with CFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <64bb37e0708270932h56d8744eo5ae118bdf9e8cc10@mail.gmail.com>
Date:	Mon, 27 Aug 2007 18:32:28 +0200
From:	"Torsten Kaiser" <just.for.lkml@...glemail.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	nickpiggin@...oo.com.au, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [patch] sched: fix broken smt/mc optimizations with CFS

On 8/23/07, Ingo Molnar <mingo@...e.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/