From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752226AbcFZLaO (ORCPT ); Sun, 26 Jun 2016 07:30:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:58785 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752112AbcFZLaM (ORCPT ); Sun, 26 Jun 2016 07:30:12 -0400 Subject: Re: [PATCH 1/2] cgroup: pids: show number of failed forks since limit reset To: Tejun Heo References: <20160624030049.13341-1-asarai@suse.de> <20160624030049.13341-2-asarai@suse.de> <20160624153151.GQ3262@mtj.duckdns.org> Cc: Jonathan Corbet , Li Zefan , Johannes Weiner , Kenny Yu , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org From: Aleksa Sarai Message-ID: <78d17b23-d712-7d9c-3655-34c646bc4897@suse.de> Date: Sun, 26 Jun 2016 21:34:41 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160624153151.GQ3262@mtj.duckdns.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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 limit change manually. In addition, we log the first >> failure since the limit was reset (which was the original semantics of >> the patchset). > > Isn't that trivially achievable by reading the counter and then > calculating the diff? I don't think it matters all that much whether > the log message is printed once per cgroup or per config-change. It's > just a hint for the admin to avoid setting her off on a wild goose > chase. 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. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/