From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752175AbdFUVuQ convert rfc822-to-8bit (ORCPT ); Wed, 21 Jun 2017 17:50:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38500 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751893AbdFUVuO (ORCPT ); Wed, 21 Jun 2017 17:50:14 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5AF2861D24 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=longman@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5AF2861D24 Subject: Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process constraint To: Tejun Heo Cc: Li Zefan , Johannes Weiner , Peter Zijlstra , Ingo Molnar , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, efault@gmx.de, torvalds@linux-foundation.org References: <1497452737-11125-1-git-send-email-longman@redhat.com> <1497452737-11125-2-git-send-email-longman@redhat.com> <20170621204050.GA14720@htj.duckdns.org> <0c752151-f4aa-cda0-ba36-77cdc7dc25c6@redhat.com> <20170621213905.GD14720@htj.duckdns.org> From: Waiman Long Organization: Red Hat Message-ID: <6c115cf4-e229-413c-f63f-26fb8fd870d9@redhat.com> Date: Wed, 21 Jun 2017 17:50:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170621213905.GD14720@htj.duckdns.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 21 Jun 2017 21:50:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/21/2017 05:39 PM, Tejun Heo wrote: > Hello, > > On Wed, Jun 21, 2017 at 05:37:00PM -0400, Waiman Long wrote: >>> What happens when we add domain handling to CPU so that it is both a >>> domain and resource controller? Even if that somehow can be resolved, >>> wouldn't that come with a rather surprising userland behavior changes? >>> Also, I'm not sure what we're achieving by doing this. It doesn't >>> really relax the restriction. It just turns it off implicitly when >>> certain conditions are met, which doesn't really allow any real >>> capabilities and at least to me the behaviors feel more subtle and >>> complicated than before. >> I think CPU isn't a good example for that. > Can you please elaborate? CPU is probably the most prominent controller where deep hierarchy has a performance cost. So I can't envision that it will forbid internal process competition. >> Another alternative is to treat no internal process as a controller >> attribute. Then we don't need to worry about this intricate question and >> let the controllers decide if they will allow internal processes. > Isn't that what "threaded" is? > That is exactly what this patch intends to do. However, you raised concern that threaded may not be equivalent to the need of allowing internal process. That is why I propose that. If your concern is only about the documentation change, we can certainly fix that. Cheers, Longman