All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miao Xie <miaox@cn.fujitsu.com>
To: Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] sched: fair group's bug
Date: Fri, 09 Jan 2009 10:45:06 +0800	[thread overview]
Message-ID: <4966BA32.5000400@cn.fujitsu.com> (raw)
In-Reply-To: <4965573B.60801@cn.fujitsu.com>

on 2009-1-8 9:30 Miao Xie wrote:
> I tested fair group scheduler on my hyper-threading x86_64 box(2 CPU * 2 HT)
> and found the deviation of the groups' CPU usage was larger than 2.6.26
> when *offline* a CPU or do hotplug frequently. It is less than 1% On 2.6.26,but
> On current kernel, it is often greater than 4%, even than 10% by accident.
> 

This patch fixed the following problems. But the regression above still exists.

commit 0a582440ff546e2c6610d1acec325e91b4efd313
Author: Mike Galbraith <efault@gmx.de>
Date:   Fri Jan 2 12:16:42 2009 +0100

    sched: fix sched_slice()

    Impact: fix bad-interactivity buglet

    Fix sched_slice() to emit a sane result whether a task is currently
    enqueued or not.

    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Tested-by: Jayson King <dev@jaysonking.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

> 
> Besides that, We found other problems by the attached program.
> 1. some tasks are hungry in the fair group.
> 	Steps to reproduce:
> 	# mkdir /dev/cpuctl
> 	# mount -t cgroup -o cpu,noprefix xxx /dev/cpuctl
> 	# ./cpuctl -g 1 -v
> 	--------------------
> 	1th Check Result:
> 	Group	Shares	Actual(%)	Expect(%)
> 	0	1024	100.00		100.00
> 	Each task's usage:
> 		Task in Group 0:
> 			Task	Usage(%)
> 			5395	0.000000
> 			5396	0.000000
> 		 	5397	0.000000
> 			5398	16.677785
> 			5399	16.677785
> 			5400	16.744496
> 			5401	16.611074
> 			5402	33.288859
> 
> 2. some groups broke the limit of the fair group and get more CPU time When
>    the groups is hiberarchy. Such as:
> 		top group
> 		    |
> 		 group 1
> 		/	\
> 	      task1	group 2
> 			   |
> 			task 2
> 	Steps to reproduce:
> 	# mkdir /dev/cpuctl
> 	# mount -t cgroup -o cpu,noprefix xxx /dev/cpuctl
> 	# ./cpuctl -H
> 	-------------------------
> 	Group	Shares	Actual(%)	Expect(%)
> 	0	1024	60.17		88.89
> 	1	1024    39.83		11.11
> 



      parent reply	other threads:[~2009-01-09  2:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08  1:30 [BUG] sched: fair group's bug Miao Xie
2009-01-08  3:35 ` Miao Xie
2009-01-08 14:16 ` Peter Zijlstra
2009-02-23 11:09   ` Miao Xie
2009-01-09  2:45 ` Miao Xie [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=4966BA32.5000400@cn.fujitsu.com \
    --to=miaox@cn.fujitsu.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.