From: Max Kellermann <mk-xMchvyqCc6DQT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] cgroup_pids: add fork limit
Date: Tue, 10 Nov 2015 18:06:12 +0100 [thread overview]
Message-ID: <20151110170612.GA21582@rabbit.intern.cm-ag> (raw)
In-Reply-To: <20151110153746.GA20758-Rjmu19FXx3rR8JxBgnUBv+rzNCUFrscg@public.gmane.org>
On 2015/11/10 16:44, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Nov 10, 2015 at 04:37:46PM +0100, Max Kellermann wrote:
> > There's "cpu" which changes priority
>
> The cpu controller can limit both in terms of relative weight and
> absolute CPU cycle bandwidth.
No, Tejun, the "cpu" controller does not do what my feature does: like
I said, it only changes the priority, or let's rephrase (to account
for the "absolute CPU cycle bandwith" thing): it changes the amount of
CPU cycles a process gets every period.
But it does NOT put an upper limit on total consumed CPU cycles! It
will only slow down a frantic process, but it will not stop it.
Stopping it is what I want. Once process crosses the limits I
configured, there's no point in keeping it running.
You may disagree that the feature I implemented is useful, and you may
not want it merged, but do not say that I missed a kernel feature,
because that's not true.
The Linux kernel currently does not have a feature that can emulate
the fork limit that I implemented. Useful or not, it doesn't exist.
Max
WARNING: multiple messages have this Message-ID (diff)
From: Max Kellermann <mk@cm4all.com>
To: Tejun Heo <tj@kernel.org>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cgroup_pids: add fork limit
Date: Tue, 10 Nov 2015 18:06:12 +0100 [thread overview]
Message-ID: <20151110170612.GA21582@rabbit.intern.cm-ag> (raw)
In-Reply-To: <20151110153746.GA20758@rabbit.intern.cm-ag>
On 2015/11/10 16:44, Tejun Heo <tj@kernel.org> wrote:
> On Tue, Nov 10, 2015 at 04:37:46PM +0100, Max Kellermann wrote:
> > There's "cpu" which changes priority
>
> The cpu controller can limit both in terms of relative weight and
> absolute CPU cycle bandwidth.
No, Tejun, the "cpu" controller does not do what my feature does: like
I said, it only changes the priority, or let's rephrase (to account
for the "absolute CPU cycle bandwith" thing): it changes the amount of
CPU cycles a process gets every period.
But it does NOT put an upper limit on total consumed CPU cycles! It
will only slow down a frantic process, but it will not stop it.
Stopping it is what I want. Once process crosses the limits I
configured, there's no point in keeping it running.
You may disagree that the feature I implemented is useful, and you may
not want it merged, but do not say that I missed a kernel feature,
because that's not true.
The Linux kernel currently does not have a feature that can emulate
the fork limit that I implemented. Useful or not, it doesn't exist.
Max
next prev parent reply other threads:[~2015-11-10 17:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 14:06 [PATCH] cgroup_pids: add fork limit Max Kellermann
[not found] ` <144716440621.20175.1000688899886388119.stgit-Rjmu19FXx3rR8JxBgnUBv+rzNCUFrscg@public.gmane.org>
2015-11-10 15:12 ` Tejun Heo
2015-11-10 15:12 ` Tejun Heo
2015-11-10 15:37 ` Max Kellermann
[not found] ` <20151110153746.GA20758-Rjmu19FXx3rR8JxBgnUBv+rzNCUFrscg@public.gmane.org>
2015-11-10 15:44 ` Tejun Heo
2015-11-10 15:44 ` Tejun Heo
2015-11-10 17:06 ` Max Kellermann [this message]
2015-11-10 17:06 ` Max Kellermann
2015-11-10 17:29 ` Tejun Heo
[not found] ` <20151110172915.GA13740-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-11-10 17:52 ` Max Kellermann
2015-11-10 17:52 ` Max Kellermann
2015-11-10 15:25 ` Aleksa Sarai
2015-11-10 15:25 ` Aleksa Sarai
2015-11-10 15:58 ` Austin S Hemmelgarn
2015-11-10 16:19 ` Parav Pandit
2015-11-10 19:54 ` Austin S Hemmelgarn
[not found] ` <56424B83.2080504-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-11-15 13:36 ` Aleksa Sarai
2015-11-15 13:36 ` Aleksa Sarai
[not found] ` <CAOviyag=rHcDZj3MBR3dMbkdaOY=h1FB-78QLM3CZQe2WrrgCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-16 17:02 ` Austin S Hemmelgarn
2015-11-16 17:02 ` Austin S Hemmelgarn
2015-11-10 16:01 ` Max Kellermann
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=20151110170612.GA21582@rabbit.intern.cm-ag \
--to=mk-xmchvyqcc6dqt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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.