From: Hirofumi Nakagawa <hnakagawa@miraclelinux.com>
To: linux-kernel@vger.kernel.org
Cc: Ram Gupta <ram.gupta5@gmail.com>, Paul Menage <menage@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [RFC][PATCH][0/3] introduce rlimit cgroup
Date: Sat, 26 Jul 2008 16:46:30 +0900 [thread overview]
Message-ID: <488AD656.5060801@miraclelinux.com> (raw)
In-Reply-To: <728201270807250633vcaf8ac2r3be1d37736283385@mail.gmail.com>
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 <menage@google.com> 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 majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
prev parent reply other threads:[~2008-07-26 7:56 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
2008-07-25 6:05 ` Paul Menage
2008-07-25 13:33 ` Ram Gupta
2008-07-26 7:46 ` Hirofumi Nakagawa [this message]
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=488AD656.5060801@miraclelinux.com \
--to=hnakagawa@miraclelinux.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=ram.gupta5@gmail.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