From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Kei Tokunaga <tokunaga.keiich@jp.fujitsu.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
vatsa <vatsa@linux.vnet.ibm.com>
Subject: Re: A strange behavior of sched_fair
Date: Fri, 29 Feb 2008 10:34:45 +0100 [thread overview]
Message-ID: <1204277686.6243.52.camel@lappy> (raw)
In-Reply-To: <47C5E977.2010401@jp.fujitsu.com>
On Wed, 2008-02-27 at 17:51 -0500, Kei Tokunaga 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.
Seems the vruntime doesn't get re-set if you move tasks between groups.
sched_move_task() should call place_entity() in the context of the new
cfs_rq.
next prev parent reply other threads:[~2008-02-29 9:35 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
2008-02-29 9:34 ` Peter Zijlstra [this message]
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=1204277686.6243.52.camel@lappy \
--to=a.p.zijlstra@chello.nl \
--cc=dhaval@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tokunaga.keiich@jp.fujitsu.com \
--cc=vatsa@linux.vnet.ibm.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