" OOM? Is there some peculiarity about
memcg OOM that I'm missing?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.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
On Fri, Jun 24, 2016 at 01:00:48PM +1000, Aleksa Sarai wrote:
This allows users to dynamically adjust their limits based on how many
failed forks happened since they last reset their limits, otherwise they
would have to track (in a racy way) how many limit failures there were
since the last
set-we-log-failures-again semantics that Tejun said he liked.
Aleksa Sarai (2):
cgroup: pids: show number of failed forks since limit reset
docs: cgroup/pids: update documentation to include pids.events
Documentation/cgroup-v1/pids.txt | 18 ++
kernel/cgroup_pids.c
the limit was reset (which was the original semantics of
the patchset).
In addition, I clarified the licensing for this file.
Signed-off-by: Aleksa Sarai <asa...@suse.de>
---
kernel/cgroup_pids.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff
So that users know what the interface and meaning of the keyed values
are. In addition, mention that the only time that since=0 is when the
limit was changed.
Signed-off-by: Aleksa Sarai <asa...@suse.de>
---
Documentation/cgroup-v1/pids.txt | 18 ++
1 file changed, 18 inse
