introduce rlimit cgroup
cover introduce rlimit cgroup
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,
Quoted 3 lines
Hello,
I think existing rlimit interface isn't useful.
Why it isn't useful?
Please explain your motivation.
Quoted 2 lines
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.
Quoted 12 lines
# 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
Quoted 8 lines
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?
Quoted 9 lines
Hi Nakagawa-san,
Quoted 3 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 1 line
So, it isn't almost people required action.
What is most people required action?
Quoted 23 lines
At least, I don't think useful.
Quoted 12 lines
# 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 bytesQuoted 8 lines
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
Quoted 3 lines
in general, A complex setting file is thought as ugly. Why can't separate it?
I agree.
thanks.
Quoted 4 lines
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
Quoted 27 lines · Paul Menage
Quoted 4 lines
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
Quoted 36 lines
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
Quoted 25 lines · Paul Menage
Quoted 3 lines
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/