Hello,
Could anyone tell me which options to enable/disable to have the scheduler behavior as it was before 2.6.25 (i.e, completely disable the group scheduler)? There seems to be a lot of confusion [1] about which options to set or not set, so it would be nice if anyone could give the exact ones.
Thanks.
[1] For example, in Arch Linux the group scheduler was first enabled in 2.6.25, but due to latency issues it was quickly disabled. But after that, the following report claims to have problems with everything *GROUP* disabled and that you need to enable CGROUPS to solve them (the report links to similar reports on Gentoo and Ubuntu, so it seems the confusion is quite general):
http://bugs.archlinux.org/task/10512
On Fri, Jul 25, 2008 at 10:05:52AM -0700, Alberto Gonzalez wrote:
> Hello,
Hi Alberto
>
> Could anyone tell me which options to enable/disable to have the scheduler behavior as it was before 2.6.25 (i.e, completely disable the group scheduler)? There seems to be a lot of confusion [1] about which options to set or not set, so it would be nice if anyone could give the exact ones.
>
To switch off group scheduling completely, please set CONFIG_GROUP_SCHED
to off.
If you wish to have cgroup based group scheduling, you need to
set CONFIG_CGROUP_SCHED on (and if required CONFIG_FAIR_GROUP_SCHED for
CFS group scheduling and CONFIG_RT_GROUP_SCHED for RT group scheduling)
--
regards,
Dhaval
Alberto Gonzalez wrote:
> Hello,
>
> Could anyone tell me which options to enable/disable to have the scheduler behavior as it was before 2.6.25 (i.e, completely disable the group scheduler)? There seems to be a lot of confusion [1] about which options to set or not set, so it would be nice if anyone could give the exact ones.
>
> Thanks.
>
> [1] For example, in Arch Linux the group scheduler was first enabled in 2.6.25, but due to latency issues it was quickly disabled. But after that, the following report claims to have problems with everything *GROUP* disabled and that you need to enable CGROUPS to solve them (the report links to similar reports on Gentoo and Ubuntu, so it seems the confusion is quite general):
>
> http://bugs.archlinux.org/task/10512
>
Would be nice to have a clean way to do this at runtime, so you could
run a distribution kernel and just avoid the group part of the scheduling.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Alberto Gonzalez wrote:
> [1] For example, in Arch Linux the group scheduler was first enabled
> in 2.6.25, but due to latency issues it was quickly disabled. But
> after that, the following report claims to have problems with
> everything *GROUP* disabled and that you need to enable CGROUPS to
> solve them (the report links to similar reports on Gentoo and Ubuntu,
> so it seems the confusion is quite general):
>
> http://bugs.archlinux.org/task/10512
The linked thread talks about latency problems in the CFQ I/O scheduler,
not the process scheduler. It appears that enabling CGROUPS helps get
around the I/O scheduler issues.
Are you sure that you actually want to disable group scheduling for
processes?
Chris
On Sun, Jul 27, 2008 at 4:24 PM, Bill Davidsen <[email protected]> wrote:
> Would be nice to have a clean way to do this at runtime, so you could run a
> distribution kernel and just avoid the group part of the scheduling.
If the cgroups scheduler is enabled but you don't actually create any
cpu scheduler cgroups, then you're just scheduling across a single
group that contains all processes/threads. Is that distinguishable
from not having group scheduling at all?
Paul
Paul Menage wrote:
> On Sun, Jul 27, 2008 at 4:24 PM, Bill Davidsen <[email protected]> wrote:
>
>> Would be nice to have a clean way to do this at runtime, so you could run a
>> distribution kernel and just avoid the group part of the scheduling.
>>
>
> If the cgroups scheduler is enabled but you don't actually create any
> cpu scheduler cgroups, then you're just scheduling across a single
> group that contains all processes/threads. Is that distinguishable
> from not having group scheduling at all?
>
In decisions, hopefully not. But given that there are other places in
kernel which allow code to be bypassed completely, a flag which would
simply avoid ever going into the code would not be a new idea. In the
network code there are flags to prevent passing packets in a bridge
through iptables, something similar could be provided in scheduling. It
actually makes sense to default the flag to "no cgroups" asnd only
enable it if cgroups have been defined.
There is no optimization faster than not executing the code.
--
Bill Davidsen <[email protected]>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark