Bug#466942: use CONFIG_FAIR_CGROUP_SCHED instead of CONFIG_FAIR_GROUP_SCHED
On Sun, Sep 07, 2008 at 03:20:56PM -0300, Ivan Baldo wrote:
> The CGROUP infrastructure is the only way to allow runtime configuration
> on how the scheduler should work, so some simple DebConf questions could
> setup the system as the user wants it (even distribution between users, even
> distribution between groups, even distribution for all the processes without
> considering groups or users), and even after that, a user or sysadmin could
> further configure it.
Which configuration option is removed due to the group scheduler? I fail
to find any.
> Currently, the FAIR_GROUP_SCHED option is the worst choice, because of 2
> things:
> 1 - it forces one behaviour and there is no other way but recompile
> the kernel to change it.
No. It only extends the scheduler decision with another information.
> 2 - it changes a default behaviour used for many years! you may run a
> program with nice 19 and SCHED_IDLEPRIO and still consume a lot
> of CPU time and starve other processes. Users and sysadmins are
> used to the nice command to control priorities of processes
> without thinking about groupings by group or user id.
Please show that behaviour. By default a system have only one group and
within the group the default nice behaviour is used. Between groups the
cpu is uniformly distributed.
Proove:
| $ ps ux | grep test
| USER 15850 86.1 0.0 1740 336 pts/6 RN 22:05 0:12 ./test-nice-10
| USER 15851 11.3 0.0 1740 336 pts/6 RN 22:05 0:01 ./test-nice-19
| $ uname -a
| Linux HOST 2.6.26-1-powerpc64 #1 SMP Mon Aug 25 00:33:17 UTC 2008 ppc64 GNU/Linux
Both processes runs in a cgroup which is restricted to one cpu.
Bastian
--
You canna change the laws of physics, Captain; I've got to have thirty minutes!
Reply to: