[lkml]   [2008]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [-mm][PATCH 0/4] Add rlimit controller to cgroups (v3)
>Subject: [-mm][PATCH 0/4] Add rlimit controller to cgroups (v3)
>This is the third version of the address space control patches. These
>patches are against 2.6.25-mm1 and have been tested using KVM in SMP mode,
>both with and without the config enabled.
>The first patch adds the user interface. The second patch fixes the
>cgroup mm_owner_changed callback to pass the task struct, so that
>accounting can be adjusted on owner changes. The thrid patch adds accounting
>and control. The fourth patch updates documentation.
>An earlier post of the patchset can be found at
>This patch is built on top of the mm owner patches and utilizes that feature
>to virtually group tasks by mm_struct.
>Reviews, Comments?

I can't read the whole patch deeply now but this new concept "rlimit-controlle
r" seems make sense to me.

At quick glance, I have some thoughts.

1. kerner/rlimit_cgroup.c is better for future expansion.
2. why
"+This controller framework is designed to be extensible to control any
"+resource limit (memory related) with little effort."
memory only ? Ok, all you want to do is related to memory, but someone
may want to limit RLIMIT_CPU by group or RLIMIT_CORE by group or....
(I have no plan but they seems useful.;)
So, could you add design hint of rlimit contoller to the documentation ?

3. Rleated to 2. Showing what kind of "rlimit" params are supported by
cgroup will be good.

I don't think you have to implement all things at once. Staring from
"only RLIMIT_AS is supported now" is good. Someone will expand it if
he needs. But showing basic view of "gerenal purpose rlimit contoller" in _doc
ument_ or _comments_ or _codes_ is a good thing to do.

If you don't want to provide RLIMIT feature other than address space,
it's better to avoid using the name of RLIMIT. It's confusing.


 \ /
  Last update: 2008-05-04 17:27    [W:0.131 / U:1.956 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site