linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Aleksa Sarai <asarai@suse.de>
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 11:33:49 -0400	[thread overview]
Message-ID: <20160629153349.GA28719@htj.duckdns.org> (raw)
In-Reply-To: <ec289e47-9761-ff21-b264-1391aa22cfd4@suse.de>

Hello, Aleksa.

On Wed, Jun 29, 2016 at 03:10:26PM +1000, Aleksa Sarai wrote:
> 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,

Kernel logging may be an enough hint for a human admin but is an awful
mechanism for any programs trying to monitor.

> 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.

First of all, a situation where a cgroup hits its limits and then can
proceed normally after the limit is lifted would be very rare.
Secondly, even in those corner cases, synchronization between config
update and event counter doesn't matter.  For dynamic adjustments to
work, fork failures have to be cleanly recoverable and thus the user
can just start monitoring after the config is bumped up - if it fails
again, adjust again; otherwise, it's all good.  It just doesn't
matter.

Thanks.

-- 
tejun

      reply	other threads:[~2016-06-29 15:34 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
2016-06-29 15:33           ` Tejun Heo [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=20160629153349.GA28719@htj.duckdns.org \
    --to=tj@kernel.org \
    --cc=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 \
    /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).