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.

> 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.
So, it isn't almost 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?






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