mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Hirofumi Nakagawa <hnakagawa@miraclelinux.com>
Cc: kosaki.motohiro@jp.fujitsu.com, linux-kernel@vger.kernel.org,
	menage@google.com
Subject: Re: [RFC][PATCH][0/3] introduce rlimit cgroup
Date: Thu, 24 Jul 2008 15:14:29 +0900	[thread overview]
Message-ID: <20080724150557.8697.KOSAKI.MOTOHIRO@jp.fujitsu.com> (raw)
In-Reply-To: <488722DF.9080003@miraclelinux.com>

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?





  reply	other threads:[~2008-07-24  6:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-23 12:23 Hirofumi Nakagawa
2008-07-24  6:14 ` KOSAKI Motohiro [this message]
2008-07-24 10:33   ` Hirofumi Nakagawa
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=20080724150557.8697.KOSAKI.MOTOHIRO@jp.fujitsu.com \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=hnakagawa@miraclelinux.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

all inboxes | Powered by JetHome®