From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751545AbdBFJuc (ORCPT ); Mon, 6 Feb 2017 04:50:32 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:54073 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750980AbdBFJua (ORCPT ); Mon, 6 Feb 2017 04:50:30 -0500 Date: Mon, 6 Feb 2017 10:50:21 +0100 From: Peter Zijlstra To: Tejun Heo Cc: Andy Lutomirski , Linux API , Li Zefan , Johannes Weiner , Ingo Molnar , Paul Turner , Mike Galbraith , "open list:CONTROL GROUP (CGROUP)" , "linux-kernel@vger.kernel.org" , kernel-team@fb.com, lvenanci@redhat.com Subject: Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode Message-ID: <20170206095021.GI6515@twins.programming.kicks-ass.net> References: <20170202200632.13992-1-tj@kernel.org> <20170202215229.GA27231@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170202215229.GA27231@htj.duckdns.org> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 02, 2017 at 04:52:29PM -0500, Tejun Heo wrote: > > Why do you need to manually turn it on? That is, couldn't it be > > automatic based on what controllers are enabled? > > This came up already but it's not like some controllers are inherently > thread-only. Consider CPU, all in-context CPU cycle consumptions are > tied to the thread; however, we also want to be able to account for > CPU cycles consumed for, for example, memory reclaim or encryption > during writeback. > > I played with an interface where thread mode is enabled automatically > upto the common ancestor of the threads but not only was it > complicated to implement but also the eventual behavior was very > confusing as the resource domain can change without any active actions > from the user. I think keeping things simple is the right choice > here. Note that the explicit marking of the resource domains gets you exactly that. But let me reply in the other subthread. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode Date: Mon, 6 Feb 2017 10:50:21 +0100 Message-ID: <20170206095021.GI6515@twins.programming.kicks-ass.net> References: <20170202200632.13992-1-tj@kernel.org> <20170202215229.GA27231@htj.duckdns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20170202215229.GA27231-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Tejun Heo Cc: Andy Lutomirski , Linux API , Li Zefan , Johannes Weiner , Ingo Molnar , Paul Turner , Mike Galbraith , "open list:CONTROL GROUP (CGROUP)" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , kernel-team-b10kYP2dOMg@public.gmane.org, lvenanci-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org List-Id: linux-api@vger.kernel.org On Thu, Feb 02, 2017 at 04:52:29PM -0500, Tejun Heo wrote: > > Why do you need to manually turn it on? That is, couldn't it be > > automatic based on what controllers are enabled? > > This came up already but it's not like some controllers are inherently > thread-only. Consider CPU, all in-context CPU cycle consumptions are > tied to the thread; however, we also want to be able to account for > CPU cycles consumed for, for example, memory reclaim or encryption > during writeback. > > I played with an interface where thread mode is enabled automatically > upto the common ancestor of the threads but not only was it > complicated to implement but also the eventual behavior was very > confusing as the resource domain can change without any active actions > from the user. I think keeping things simple is the right choice > here. Note that the explicit marking of the resource domains gets you exactly that. But let me reply in the other subthread.