lkml.org 
[lkml]   [2008]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [-mm][PATCH 0/4] Add rlimit controller to cgroups (v3)
kamezawa.hiroyu@jp.fujitsu.com wrote:
>>
>> 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
>> http://lwn.net/Articles/275143/
>>
>> 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.

I have no problem with that name, I can rename the files.

> 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.;)

I currently mentioned memory, since we have the infrastructure to group using
mm->owner infrastructure. For other purposes, we'll need to enhance the
controller quite a bit. That is why I put memory related in brackets.

> So, could you add design hint of rlimit contoller to the documentation ?
>

OK, I'll update the documentation

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

Do you mean in init/Kconfig or documentation?. I should probably rename
limit_in_bytes and usage_in_bytes to add an as_ prefix, so that the UI clearly
shows what is supported as well.

> 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.
>

I can add to the documentation

> 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.
>

I used RLIMIT since I want to extend it later to control memory locked pages :)
I open to other names as well.

> Thanks,
> -Kame
>
>
>
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>


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


\
 
 \ /
  Last update: 2008-05-05 06:25    [W:0.100 / U:4.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site