[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: