From: Tejun Heo <tj@kernel.org>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Markus Elfring <elfring@users.sourceforge.net>,
"David S. Miller" <davem@davemloft.net>,
Nicolas Dichtel <nicolas.dichtel@6wind.com>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>
Subject: Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
Date: Mon, 18 Jul 2016 18:52:49 -0400 [thread overview]
Message-ID: <20160718225249.GM3078@mtj.duckdns.org> (raw)
In-Reply-To: <f6f93ae6-48c4-bce9-08a2-5067919e8748@gmail.com>
On Fri, Jul 15, 2016 at 05:15:41PM +0000, Topi Miettinen wrote:
> There are clear semantics for the limits themselves, either they apply
> per task or per user. It makes sense to gather values according to these
> semantics. Then with systemd or other tools you can use the valuse to
> set the limits for a service regardless if the limit applies per task or
> per user and it works according to each limit's semantics.
What does it mean to collect the maximum of the high watermarks of
multiple users or the high water marks along process hierarchy which
is spread across multiple cgroups? These are non-sensical numbers.
If you want to collect high watermarks per-cgroup, the numbers have to
be per-cgroup - how many fds are being used in that particular cgroup
and what's the high watermark of that number and so on. You can't
just take maximum from process hierarchy or user watermarks.
Thanks.
--
tejun
next prev parent reply other threads:[~2016-07-18 22:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1468578983-28229-1-git-send-email-toiwoton@gmail.com>
2016-07-15 10:35 ` [PATCH 01/14] resource limits: foundation for resource highwater tracking Topi Miettinen
2016-07-15 12:12 ` kbuild test robot
2016-07-15 12:49 ` Nicolas Dichtel
2016-07-15 16:27 ` Topi Miettinen
2016-07-15 17:57 ` Nicolas Dichtel
2016-07-15 10:35 ` [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level Topi Miettinen
2016-07-15 12:38 ` kbuild test robot
2016-07-15 14:10 ` Tejun Heo
2016-07-15 17:15 ` Topi Miettinen
2016-07-18 22:52 ` Tejun Heo [this message]
2016-07-19 16:57 ` Topi Miettinen
2016-07-19 18:18 ` Tejun Heo
2016-07-15 10:35 ` [PATCH 03/14] resource limits: track highwater mark of file sizes Topi Miettinen
2016-07-15 10:35 ` [PATCH 04/14] resource limits: track highwater mark of VM data segment Topi Miettinen
2016-07-15 10:35 ` [PATCH 05/14] resource limits: track highwater mark of stack size Topi Miettinen
2016-07-15 10:35 ` [PATCH 06/14] resource limits: track highwater mark of cores dumped Topi Miettinen
2016-07-15 10:35 ` [PATCH 07/14] resource limits: track highwater mark of user processes Topi Miettinen
2016-07-15 10:35 ` [PATCH 08/14] resource limits: track highwater mark of number of files Topi Miettinen
2016-07-15 10:35 ` [PATCH 10/14] resource limits: track highwater mark of address space size Topi Miettinen
2016-07-15 10:35 ` [PATCH 11/14] resource limits: track highwater mark of number of pending signals Topi Miettinen
2016-07-15 10:35 ` [PATCH 12/14] resource limits: track highwater mark of size of message queues Topi Miettinen
2016-07-15 10:36 ` [PATCH 13/14] resource limits: track highwater mark of niceness Topi Miettinen
2016-07-15 10:36 ` [PATCH 14/14] resource limits: track highwater mark of RT priority Topi Miettinen
2016-07-15 17:42 ` [PATCH 00/14] Present useful limits to user (v2) Topi Miettinen
[not found] ` <20160715124330.GR30154@twins.programming.kicks-ass.net>
[not found] ` <28b4b919-4f50-d9f6-c5e1-d1e92ea1ba1c@gmail.com>
[not found] ` <20160715135956.GA3115@twins.programming.kicks-ass.net>
2016-07-15 20:54 ` H. Peter Anvin
2016-07-18 13:00 ` Austin S. Hemmelgarn
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=20160718225249.GM3078@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=elfring@users.sourceforge.net \
--cc=hannes@cmpxchg.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=nicolas.dichtel@6wind.com \
--cc=toiwoton@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
all inboxes | Powered by JetHome®