Bug#466942: use CONFIG_FAIR_CGROUP_SCHED instead of CONFIG_FAIR_GROUP_SCHED
 

Hello.
Thanks for your answer!
I got confused! I tried something like your example and yes, it
works very well and as intended. Then after a more careful look I
noticed that the kernel is using the CGROUPS infrastructure so what I
said doesn't apply. Sorry for the noise.
I have problems with bad interactivity of the system, it is not
graphics specific, is not sound specific... If I have a couple of cpu
intensive tasks running with nice 19, and then a couple running with
nice 0, the system feels slow to react even on the console, and it
doesn't happen with 2.6.24...
I have compiled a kernel without CONFIG_FAIR_GROUP_SCHED, another
without CONFIG_GROUP_SCHED and another with 1000HZ, CONFIG_SLUB,
CONFIG_PREEMPT, CONFIG_PREEMPT_RCU and without CONFIG_CLASSIC_RCU, all
this kernels had the same problem on my system (Athlon64x2 3Ghz DDR2-800
Dual Channel).

If you have some suggestions on things to try I will appreciate it.
Thanks!
p.s.: BTW, this bug should be closed since the kernel doesn't use
CONFIG_FAIR_USER_SCHED anymore.





El 07/09/08 17:11, Bastian Blank escribió:

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




--
Ivan Baldo - ibaldo@adinet.com.uy - http://ibaldo.codigolibre.net/
From Montevideo, Uruguay, at the south of South America.
Freelance programmer and GNU/Linux system administrator, hire me!
Alternatives: ibaldo@codigolibre.net - http://go.to/ibaldo




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org