[RFC][PATCH][0/3] introduce rlimit cgroup

[RFC][PATCH][0/3] introduce rlimit cgroup

[Hirofumi Nakagawa]

Hello,

I think existing rlimit interface isn't useful.
So I created rlimit interface on cgroup.
Do you think this is a proper way todo it? (or Is there any similar methods already?)

usage
=======================================
# mkdir /dev/cgroup
# mount -t cgroup -o rlimit none /dev/cgroup
# ls /dev/cgroup
notify_on_release  release_agent  rlimit.limits  tasks
# 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
[1]    2854 file size limit exceeded  cat /dev/zero > /tmp/hoge

Re: [RFC][PATCH][0/3] introduce rlimit cgroup

[KOSAKI Motohiro]

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?

Re: [RFC][PATCH][0/3] introduce rlimit cgroup

[Hirofumi Nakagawa]

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

Re: [RFC][PATCH][0/3] introduce rlimit cgroup

[Paul Menage]

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

No, there's no way to do that currently. I'm not sure if it's
generally safe to update the rlimit for another process.

If we're trying to use rlimits in a cgroup context then some rlimits
(e.g. max nice priority) ought to apply as additional caps on the
processes in the cgroup (e.g. if you set a max nice priority of 1 on a
cgroup, that ought to override any per-process settings) whereas
others (e.g. locked memory, open files, num processes) ought to apply
as an aggregate limit on the cgroup (so the sum of all open files
across the cgroup shouldn't be able to exceed the cgroup's "open
files" limit). E.g. see Balbir's memrlimit control groups patches that
are currently in -mm.

What concrete problem are you trying to solve here?

Paul

Re: [RFC][PATCH][0/3] introduce rlimit cgroup

[Ram Gupta]

I understand that there might be some cases where it is useful to
allow some process to set rlimits of other processes (e.g. some
launcher process might want to control resources of all the
applications being launched by it). But this has to be a very special
case or this process needs to have special permission to do that
otherwise there will be a lot of problems as a side effect.

Ram

On Fri, Jul 25, 2008 at 1:05 AM, Paul Menage <menage@google.com> wrote:
>>
>> 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.
>
> No, there's no way to do that currently. I'm not sure if it's
> generally safe to update the rlimit for another process.
>
> If we're trying to use rlimits in a cgroup context then some rlimits
> (e.g. max nice priority) ought to apply as additional caps on the
> processes in the cgroup (e.g. if you set a max nice priority of 1 on a
> cgroup, that ought to override any per-process settings) whereas
> others (e.g. locked memory, open files, num processes) ought to apply
> as an aggregate limit on the cgroup (so the sum of all open files
> across the cgroup shouldn't be able to exceed the cgroup's "open
> files" limit). E.g. see Balbir's memrlimit control groups patches that
> are currently in -mm.
>
> What concrete problem are you trying to solve here?
>
> Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [RFC][PATCH][0/3] introduce rlimit cgroup

[Hirofumi Nakagawa]

Hi,

Thank you for your comments.
I understand that.
I'll look for other approach for this.

thanks

> I understand that there might be some cases where it is useful to
> allow some process to set rlimits of other processes (e.g. some
> launcher process might want to control resources of all the
> applications being launched by it). But this has to be a very special
> case or this process needs to have special permission to do that
> otherwise there will be a lot of problems as a side effect.
> 
> Ram
> 
> On Fri, Jul 25, 2008 at 1:05 AM, Paul Menage <menage@google.com> wrote:
>>> 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.
>> No, there's no way to do that currently. I'm not sure if it's
>> generally safe to update the rlimit for another process.
>>
>> If we're trying to use rlimits in a cgroup context then some rlimits
>> (e.g. max nice priority) ought to apply as additional caps on the
>> processes in the cgroup (e.g. if you set a max nice priority of 1 on a
>> cgroup, that ought to override any per-process settings) whereas
>> others (e.g. locked memory, open files, num processes) ought to apply
>> as an aggregate limit on the cgroup (so the sum of all open files
>> across the cgroup shouldn't be able to exceed the cgroup's "open
>> files" limit). E.g. see Balbir's memrlimit control groups patches that
>> are currently in -mm.
>>
>> What concrete problem are you trying to solve here?
>>
>> Paul
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>