From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751230AbdFBUg2 convert rfc822-to-8bit (ORCPT ); Fri, 2 Jun 2017 16:36:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46162 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750918AbdFBUg0 (ORCPT ); Fri, 2 Jun 2017 16:36:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1BDCED0A82 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 1BDCED0A82 Subject: Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics To: Tejun Heo References: <20170524212745.GP24798@htj.duckdns.org> <20170601145042.GA3494@htj.duckdns.org> <20170601151045.xhsv7jauejjis3mi@hirez.programming.kicks-ass.net> <20170601184740.GC3494@htj.duckdns.org> <20170601203815.GA13390@htj.duckdns.org> <20170601205203.GB13390@htj.duckdns.org> <1e775dcf-61b2-29d5-a214-350dc81c632b@redhat.com> <20170601211823.GC13390@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: Fri, 2 Jun 2017 16:36:22 -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: <20170601211823.GC13390@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]); Fri, 02 Jun 2017 20:36:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/01/2017 05:18 PM, Tejun Heo wrote: > Hello, > > On Thu, Jun 01, 2017 at 05:12:42PM -0400, Waiman Long wrote: >> Are you referring to keeping the no internal process restriction and >> document how to work around that instead? I would like to hear what >> workarounds are currently being used. > What we've been talking about all along - just creating explicit leaf > nodes. > >> Anyway, you currently allow internal process in thread mode, but not in >> non-thread mode. I would prefer no such restriction in both thread and >> non-thread mode. > Heh, so, these aren't arbitrary. The contraint is tied to > implementing resource domains and thread subtree doesn't have resource > domains in them, so they don't need the constraint. I'm sorry about > the short replies but I'm kinda really tied up right now. I'm gonna > do the thread mode so that it can be agnostic w.r.t. the internal > process constraint and I think it could be helpful to decouple these > discussions. We've been having this discussion for a couple years now > and it looks like we're gonna go through it all over, which is fine, > but let's at least keep that separate. I wouldn't argue further on that if you insist. However, I still want to relax the constraint somewhat by abandoning the no internal process constraint when only threaded controllers (non-resource domains) are enabled even when thread mode has not been explicitly enabled. It is a modified version my second alternative. Now the question is which controllers are considered to be resource domains. I think memory and blkio are in the list. What else do you think should be considered resource domains? Cheers, Longman any of the resource domains (!threaded) controllers are enabled.