From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751243AbdFAT1o convert rfc822-to-8bit (ORCPT ); Thu, 1 Jun 2017 15:27:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43664 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbdFAT1j (ORCPT ); Thu, 1 Jun 2017 15:27:39 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2D139D6485 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=longman@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2D139D6485 Subject: Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics To: Tejun Heo References: <1494855256-12558-1-git-send-email-longman@redhat.com> <1494855256-12558-12-git-send-email-longman@redhat.com> <20170519202624.GA15279@wtj.duckdns.org> <20170524203616.GO24798@htj.duckdns.org> <9b147a7e-fec3-3b78-7587-3890efcd42f2@redhat.com> <20170524212745.GP24798@htj.duckdns.org> <20170601145042.GA3494@htj.duckdns.org> <20170601151045.xhsv7jauejjis3mi@hirez.programming.kicks-ass.net> <20170601184740.GC3494@htj.duckdns.org> Cc: Peter Zijlstra , Li Zefan , Johannes Weiner , Ingo Molnar , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, efault@gmx.de From: Waiman Long Organization: Red Hat Message-ID: Date: Thu, 1 Jun 2017 15:27:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170601184740.GC3494@htj.duckdns.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 01 Jun 2017 19:27:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/01/2017 02:47 PM, Tejun Heo wrote: > Hello, Waiman. > > On Thu, Jun 01, 2017 at 02:44:48PM -0400, Waiman Long wrote: >>> And cgroup-v2 has this 'exception' (aka wart) for the root group which >>> needs to be replicated for each namespace. >> One of the changes that I proposed in my patches was to get rid of the >> no internal process constraint. I think that will solve a big part of >> the container invariant problem that we have with cgroup v2. > I'm not sure. It just masks it without actually solving it. I mean, > the constraint is thereq for a reason. "Solving" it would defeat one > of the main capabilities for resource domains and masking it from > kernel side doesn't make whole lot of sense to me given that it's > something which can be easily done from userland. If we take out that > part, for controllers which don't care about resource domains, > wouldn't thread mode be a sufficient solution? As said in an earlier email, I agreed that masking it on the kernel side may not be the best solution. I offer 2 other alternatives: 1) Document on how to work around the resource domains issue by proper setup of the cgroup hierarchy. 2) Mark those controllers that require the no internal process competition constraint and disallow internal process only when those controllers are active. I prefer the first alternative, but I can go with the second if necessary. The major rationale behind my enhanced thread mode patch was to allow something like R -- A -- B \ T1 -- T2 where you can have resource domain controllers enabled in the thread root as well as some child cgroups of the thread root. As no internal process rule is currently not applicable to the thread root, this creates the dilemma that we need to deal with internal process competition. The container invariant that PeterZ talked about will also be a serious issue here as I don't think we are going to set up a container root cgroup that will have no process allowed in it because it has some child cgroups. IMHO, I don't think cgroup v2 will get wide adoption without getting rid of that no internal process constraint. Cheers, Longman