From: Hirofumi Nakagawa <hnakagawa@miraclelinux.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, menage@google.com
Subject: Re: [RFC][PATCH][0/3] introduce rlimit cgroup
Date: Thu, 24 Jul 2008 19:33:35 +0900 [thread overview]
Message-ID: <48885A7F.80106@miraclelinux.com> (raw)
In-Reply-To: <20080724150557.8697.KOSAKI.MOTOHIRO@jp.fujitsu.com>
> 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.
next prev parent reply other threads:[~2008-07-24 10:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-23 12:23 [RFC][PATCH][0/3] introduce rlimit cgroup Hirofumi Nakagawa
2008-07-24 6:14 ` KOSAKI Motohiro
2008-07-24 10:33 ` Hirofumi Nakagawa [this message]
2008-07-25 6:05 ` Paul Menage
2008-07-25 13:33 ` Ram Gupta
2008-07-26 7:46 ` Hirofumi Nakagawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48885A7F.80106@miraclelinux.com \
--to=hnakagawa@miraclelinux.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox