From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423350AbcFMV7i (ORCPT ); Mon, 13 Jun 2016 17:59:38 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36436 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422745AbcFMV7g (ORCPT ); Mon, 13 Jun 2016 17:59:36 -0400 Subject: Re: [RFC 02/18] cgroup_pids: track maximum pids To: Tejun Heo 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> Cc: linux-kernel@vger.kernel.org, Li Zefan , Johannes Weiner , "open list:CONTROL GROUP (CGROUP)" From: Topi Miettinen Openpgp: id=A0F2EB0D8452DA908BEC8E911CF9ADDBD610E936 Message-ID: <15ef1041-35b6-cb31-ff98-8b0be7780bc3@gmail.com> Date: Mon, 13 Jun 2016 21:59:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160613213354.GH31708@htj.duckdns.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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)? >> 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. > > Thanks. > 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. -Topi