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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.