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
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?
> 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.
>
> 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
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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 <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>