From: Aleksa Sarai <asarai@suse.de>
To: Tejun Heo <tj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>, Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>, Kenny Yu <kennyyu@fb.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org
Subject: Re: [PATCH 1/2] cgroup: pids: show number of failed forks since limit reset
Date: Wed, 29 Jun 2016 15:10:26 +1000 [thread overview]
Message-ID: <ec289e47-9761-ff21-b264-1391aa22cfd4@suse.de> (raw)
In-Reply-To: <20160626234258.GJ9219@stj.duckdns.org>
> On Sun, Jun 26, 2016 at 09:34:41PM +1000, Aleksa Sarai wrote:
>> If a user has a setup where they wait for notifications on changes to
>> pids.event, and then auto-adjust the cgroup limits based on the number of
>> failures you have a race condition between reading the pids.event file and
>> then setting the new limit. Then, upon getting notified again there may have
>> been many failed forks with the old limit set, so you might decide to bump
>> up the limit again.
>>
>> It's not a huge deal, I just though it could be useful to alleviate problems
>> like the above.
>
> This is something which can easily be avoided from userland. I don't
> think we need to add extra facilities for this.
Maybe I'm misunderstanding what the purpose of pids.events is meant to
be. If it's just meant to be a "hint" to the administrator, then that
seems like an awfully odd way of giving hints (the kernel logging should
be enough for that). If it's meant so that the administrator can make
policy decisions, then she won't know if the change in failures happened
before or after she adjusted the limit.
I also don't see what you mean by "it can be avoided from userland".
There's a race between changing pids.max and a process forking that
causes pids.events to be updated.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
next prev parent reply other threads:[~2016-06-29 5:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 3:00 [PATCH 0/2] cgroup: pids: extend pids.events Aleksa Sarai
2016-06-24 3:00 ` [PATCH 1/2] cgroup: pids: show number of failed forks since limit reset Aleksa Sarai
2016-06-24 3:00 ` [PATCH 2/2] docs: cgroup/pids: update documentation to include pids.events Aleksa Sarai
2016-06-24 15:31 ` [PATCH 1/2] cgroup: pids: show number of failed forks since limit reset Tejun Heo
2016-06-26 11:34 ` Aleksa Sarai
2016-06-26 23:42 ` Tejun Heo
2016-06-29 5:10 ` Aleksa Sarai [this message]
2016-06-29 15:33 ` Tejun Heo
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=ec289e47-9761-ff21-b264-1391aa22cfd4@suse.de \
--to=asarai@suse.de \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=hannes@cmpxchg.org \
--cc=kennyyu@fb.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).