From: Andrew Morton <akpm@linux-foundation.org>
To: Kei Tokunaga <tokunaga.keiich@jp.fujitsu.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org, containers@lists.osdl.org
Subject: Re: A strange behavior of sched_fair
Date: Thu, 28 Feb 2008 23:08:20 -0800 [thread overview]
Message-ID: <20080228230820.22ad38b3.akpm@linux-foundation.org> (raw)
In-Reply-To: <47C5E977.2010401@jp.fujitsu.com>
(cc containers list)
On Wed, 27 Feb 2008 17:51:35 -0500 Kei Tokunaga <tokunaga.keiich@jp.fujitsu.com> wrote:
> Hi Ingo,
>
> I am playing around with sched_fair and cgroup, and it seems like
> I hit a possible bug. Could you also check if that is a bug?
>
> Description of behavior:
> Start a cpu-bound task (t1), attach it to a cgroup (cgA), and let the
> task to run for a while (e.g. several tens of seconds or a couple of
> minutes would be adequate.) Then, start another cpu-bound task (t2)
> and attach it to cgA in the way described in "Steps to Reproduce" section.
> You will see t1 does not get run for a while.
> (The tasks may not have to be cpu-bound, but it is easier to see the
> behavior using cpu-bound tasks.)
>
> How reproducible:
> Always.
>
> Environments where I saw the behavior:
> 2.6.25-rc3 with resource management functions enabled on ia64 box.
>
> Steps to Reproduce:
> # mkdir /dev/cgroup
> # mount -t cgroup -ocpuset,cpu cpu /dev/cgroup
> # mkdir /dev/cgroup/{a,b}
> # echo 0 > /dev/cgroup/a/cpuset.cpus
> # echo 0 > /dev/cgroup/b/cpuset.cpus
> # echo 1 > /dev/cgroup/a/cpuset.mems
> # echo 1 > /dev/cgroup/b/cpuset.mems
> # echo $$ > /dev/cgroup/b/tasks
> # ./a.out & echo $! > /dev/cgroup/a/tasks (a.out is just a for-loop program)
> [Wait for several tens of seconds or a couple of minutes.]
> # ./a.out2 & echo $! > /dev/cgroup/a/tasks (a.out2 is just a for-loop program)
> [You will see a.out does not get run for a while by running top command.]
>
> Additional Info:
> a.out2 needs to be started from the shell of cgroup-b in order to
> reproduce the problem (, unless the system is UP.) Starting a.out2
> in the manner, se->vruntime (or something to create the se->vruntime)
> of a.out2 seems to be initialized to a small value, compared to the
> value of a.out. And the fair scheduler only runs a.out2 until the
> se->vruntime catches up with the se->vruntime of a.out.
>
> Thanks,
> Kei
> --
> Kei Tokunaga
> Fujitsu (Red Hat On-site Partner)
next prev parent reply other threads:[~2008-02-29 7:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-27 22:51 A strange behavior of sched_fair Kei Tokunaga
2008-02-29 7:08 ` Andrew Morton [this message]
2008-02-29 9:34 ` Peter Zijlstra
2008-02-29 10:11 ` Peter Zijlstra
2008-02-29 19:42 ` Ingo Molnar
2008-02-29 20:21 ` Kei Tokunaga
2008-02-29 20:32 ` Ingo Molnar
2008-02-29 22:46 ` Kei Tokunaga
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=20080228230820.22ad38b3.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=containers@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tokunaga.keiich@jp.fujitsu.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