OpenVZ Forum


Home » Mailing lists » Devel » Re: Loadable cgroup subsystems
Re: Loadable cgroup subsystems [message #29182] Tue, 08 April 2008 09:41 Go to next message
Paul Menage is currently offline  Paul Menage
Messages: 642
Registered: September 2006
Senior Member
On Tue, Apr 8, 2008 at 2:40 AM, Nikanth Karthikesan <knikanth@suse.de> 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
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
RE: Loadable cgroup subsystems [message #29231 is a reply to message #29182] Wed, 09 April 2008 08:31 Go to previous message
Satoshi UCHIDA is currently offline  Satoshi UCHIDA
Messages: 32
Registered: April 2008
Member
> >  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


_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
Previous Topic: [RFC][PATCH] CGroups: Include hierarchy ids in /proc/<pid>/cgroup
Next Topic: [PATCH][SCTP]: IPv4 vs IPv6 addresses mess in sctp_inet[6]addr_event.
Goto Forum:
  


Current Time: Mon Jun 24 20:27:10 GMT 2024

Total time taken to generate the page: 0.02830 seconds