From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423474AbcFMWJa (ORCPT ); Mon, 13 Jun 2016 18:09:30 -0400 Received: from mail-yw0-f193.google.com ([209.85.161.193]:36353 "EHLO mail-yw0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422832AbcFMWJ2 (ORCPT ); Mon, 13 Jun 2016 18:09:28 -0400 Date: Mon, 13 Jun 2016 18:09:25 -0400 From: Tejun Heo To: Topi Miettinen Cc: linux-kernel@vger.kernel.org, Li Zefan , Johannes Weiner , "open list:CONTROL GROUP (CGROUP)" Subject: Re: [RFC 02/18] cgroup_pids: track maximum pids Message-ID: <20160613220925.GI31708@htj.duckdns.org> References: <1465847065-3577-1-git-send-email-toiwoton@gmail.com> <1465847065-3577-3-git-send-email-toiwoton@gmail.com> <20160613211227.GG31708@htj.duckdns.org> <17cb1a37-47b1-dbd4-6835-efad3cf6c12f@gmail.com> <20160613213354.GH31708@htj.duckdns.org> <15ef1041-35b6-cb31-ff98-8b0be7780bc3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15ef1041-35b6-cb31-ff98-8b0be7780bc3@gmail.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 13, 2016 at 09:59:32PM +0000, Topi Miettinen wrote: > On 06/13/16 21:33, Tejun Heo wrote: > > Hello, > > > > On Mon, Jun 13, 2016 at 09:29:32PM +0000, Topi Miettinen wrote: > >> I used fork callback as I don't want to lower the watermark in all cases > >> where the charge can be lowered, so I'd update the watermark only when > >> the fork really happens. > > > > I don't think that would make a noticeable difference. That's where > > we decide whether to grant fork or not after all and thus where the > > actual usage is. > > > > You mean, increment count on cgroup_can_fork()? But what if the fork() > fails after that (signal_pending case)? That number isn't gonna deviate by any significant amount and the counter is to estimate what the limit should be set to to begin with. It's logical to collect how close the usage got to can_attach failure due to limit breach. > >> Is there a better way to compare and set? I don't think atomic_cmpxchg() > >> does what's needed, > > > > cmpxchg loop should do what's necessary although I'm not sure how much > > being strictly correct matters here. > > These are not used for any decisions taken by kernel, but by the user. I > have to say I don't know where's the line between strict correctness and > less strict. Provided that cmpxchg is done only when the counter needs to be actually updated, it's not gonna be noticeably expensive. Might as well make it correct. Thanks. -- tejun