Loadable cgroup subsystems

Loadable cgroup subsystems

[Nikanth Karthikesan]

> On 4/1/08, Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:
>  > > > > --- a/include/linux/cgroup_subsys.h
>  > > > > +++ b/include/linux/cgroup_subsys.h
>  > > > > @@ -42,3 +42,9 @@ SUBSYS(mem_cgroup)
>  > > > > #endif
>  > > > >
>  > > > > /* */
>  > > > > +
>  > > > > +#ifdef CONFIG_CGROUP_DEVICE
>  > > > > +SUBSYS(devices)
>  > > > > +#endif
>  > > > > +
>  > > > > +/* */
>  > > >
>  > > > I don't know what this is, but it does not look like C...
>  > >
>  > > Huh?
>  >
>  > Empty comments as separators?
> 
>  They help when multiple people add such SUBSYS things and
>  do not have to fight rejects.
> 

Why not provide a interface to add subsystems at run-time instead?
Are there any reason for not letting a subsystem to be implemented as a
loadable module? IOW make cgroups usable by modules?

Thanks
Nikanth Karthikesan

Re: Loadable cgroup subsystems

[Paul Menage]

On Mon, Apr 7, 2008 at 10:39 PM, Nikanth Karthikesan <knikanth-l3A5Bk7waGM@public.gmane.org> wrote:
>
>  Why not provide a interface to add subsystems at run-time instead?
>  Are there any reason for not letting a subsystem to be implemented as a
>  loadable module? IOW make cgroups usable by modules?
>

Having all the subsystems declared at compile time makes a lot of
things (number of subsystems, size of css_set, etc) statically known,
which makes the code clearer and more importantly eliminates a bunch
of locking/synchronization overhead.

It would be possible to make cgroups support dynamically-loaded
subsystems, and in fact, some of the earliest cgroups patches did
support this, for a predefined max number of subsystems. But it would
introduce more complexity and overhead.

I'd rather not add support for this without a strong case of a
subsystem that really needs to be dynamically loaded.

Paul

Re: Loadable cgroup subsystems

[Balbir Singh]

Paul Menage wrote:
> On Mon, Apr 7, 2008 at 10:39 PM, Nikanth Karthikesan <knikanth-l3A5Bk7waGM@public.gmane.org> wrote:
>>  Why not provide a interface to add subsystems at run-time instead?
>>  Are there any reason for not letting a subsystem to be implemented as a
>>  loadable module? IOW make cgroups usable by modules?
>>
> 
> Having all the subsystems declared at compile time makes a lot of
> things (number of subsystems, size of css_set, etc) statically known,
> which makes the code clearer and more importantly eliminates a bunch
> of locking/synchronization overhead.
> 
> It would be possible to make cgroups support dynamically-loaded
> subsystems, and in fact, some of the earliest cgroups patches did
> support this, for a predefined max number of subsystems. But it would
> introduce more complexity and overhead.
> 
> I'd rather not add support for this without a strong case of a
> subsystem that really needs to be dynamically loaded.
> 

I agree with most of what you just said. The biggest advantage I see of dynamic
modules is that they can be unloaded/loaded on demand. The biggest disadvantage
is that they come in much later after system initialization and might not be
fully aware of the state of the system when the specific controller is loaded.
It is trade-off, we need to see if it is worth doing.

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

Re: Loadable cgroup subsystems

[Nikanth Karthikesan]

On Mon, 2008-04-07 at 22:43 -0700, Paul Menage wrote:
> On Mon, Apr 7, 2008 at 10:39 PM, Nikanth Karthikesan <knikanth-l3A5Bk7waGM@public.gmane.org> wrote:
> >
> >  Why not provide a interface to add subsystems at run-time instead?
> >  Are there any reason for not letting a subsystem to be implemented as a
> >  loadable module? IOW make cgroups usable by modules?
> >
> 
> Having all the subsystems declared at compile time makes a lot of
> things (number of subsystems, size of css_set, etc) statically known,
> which makes the code clearer and more importantly eliminates a bunch
> of locking/synchronization overhead.
> 

true

> It would be possible to make cgroups support dynamically-loaded
> subsystems, and in fact, some of the earliest cgroups patches did
> support this, for a predefined max number of subsystems. But it would
> introduce more complexity and overhead.
> 
> I'd rather not add support for this without a strong case of a
> subsystem that really needs to be dynamically loaded.

There were some band-width control patches based on cfq + cgroups, which
I guess will mandate cfq to be built-in?

Thanks
Nikanth Karthikesan

Re: Loadable cgroup subsystems

[Paul Menage]

On Tue, Apr 8, 2008 at 2:40 AM, Nikanth Karthikesan <knikanth-l3A5Bk7waGM@public.gmane.org> wrote:
>  >
>  > I'd rather not add support for this without a strong case of a
>  > subsystem that really needs to be dynamically loaded.
>
>  There were some band-width control patches based on cfq + cgroups, which
>  I guess will mandate cfq to be built-in?
>

Yes, or else have built-in stubs for the cgroup subsystem that load
cfq and the code that uses cfq the first time someone tries to mount
that subsystem.

Actually, it probably wouldn't be too hard to have cgroups do that
automatically - support the concept of a stub cgroup that was known
about at compile time but wasn't active until its first bind, and have
cgroups dynamically load the relevant modules when the user tried to
mount it.

Dynamically loading subsystems that aren't even known about at compile
time would be probably a bit uglier.

Paul

RE: Loadable cgroup subsystems

[Satoshi UCHIDA]

> >  There were some band-width control patches based on cfq + cgroups, which
> >  I guess will mandate cfq to be built-in?
> >
> 
> Yes, or else have built-in stubs for the cgroup subsystem that load
> cfq and the code that uses cfq the first time someone tries to mount
> that subsystem.
> 

I think that it is too early to decide which band-width control for
cgroups will　mandate to be built-in.
Before that, we need more discussion about a band-width control and
its　implementation.
I seems that both implementation are still prototype and immature.
Both implementation would have good points and bad points respectively.


If you want to manage these patchset by one source tree, we should
choice adopting means by a build option.
So, I think that a build option is the better at present, but I guess
that it should be better to dynamically load subsystem in future.

I have idea that handles multiple implementation as provisional solution.
Now, all bandwidth control expands CFQ original code and is valid by build options.
It is good to be re-implemented as new I/O scheduler which reuses original code.
Therefore, it became a selectable such as other I/O scheduler (anticipatory, cfq, noop, etc.)
User can select a suitable scheduler through "scheduler" entry in sysfs. 
In addition, it's possible to use a new controller simultaneously with existing I/O scheduler.
Unfortunately, this idea would require much modification to each patchset.

-----
Satoshi UCHIDA