lkml.org 
[lkml]   [2008]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH][0/3] introduce rlimit cgroup
> Hi Nakagawa-san,
>
>> Hello,
>>
>> I think existing rlimit interface isn't useful.
>
> Why it isn't useful?
> Please explain your motivation.
>

Hi Kosaki-san,

I am sorry about lacking of explaination in my previous post.
I think setrlimit system call interface isn't useful.
Because it cannot set rlimit from other process.

>> So I created rlimit interface on cgroup.
>> Do you think this is a proper way todo it? (or Is there any similar methods already?)
>
> your rlimit controller is merely setting process rlimit to each task in the group.
>

To set rlimit from other processes is my original intention.
For I do not see a way to do it, please let me know if there were any exists.

> So, it isn't almost people required action.

What is most people required action?

> At least, I don't think useful.
>
>> # cat /dev/cgroup/rlimit.limits
>> Number Limit Soft Limit Hard Limit Unit
>> 0 Max cpu time unlimited unlimited ms
>> 1 Max file size unlimited unlimited bytes
>> 2 Max data size unlimited unlimited bytes
>> 3 Max stack size 8388608 unlimited bytes
>> 4 Max core file size 0 unlimited bytes
>> 5 Max resident set unlimited unlimited bytes
>> 6 Max processes 16300 16300 processes
>> 7 Max open files 1024 1024 files
>> 8 Max locked memory 32768 32768 bytes
>> 9 Max address space unlimited unlimited bytes
>> 10 Max file locks unlimited unlimited locks
>> 11 Max pending signals 16300 16300 signals
>> 12 Max msgqueue size 819200 819200 bytes
>> 13 Max nice priority 0 0
>> 14 Max realtime priority 0 0
>> 15 Max realtime timeout unlimited unlimited us
>> # echo "1 100000000 200000000" > /dev/cgroup/rlimit.limits
>> # cat /proc/zero > /tmp/hoge
>
> in general, A complex setting file is thought as ugly.
> Why can't separate it?
>

I agree.

thanks.



\
 
 \ /
  Last update: 2008-07-24 12:47    [W:0.053 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site