From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751653AbdBBVco (ORCPT ); Thu, 2 Feb 2017 16:32:44 -0500 Received: from mail-vk0-f47.google.com ([209.85.213.47]:36602 "EHLO mail-vk0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751245AbdBBVcl (ORCPT ); Thu, 2 Feb 2017 16:32:41 -0500 MIME-Version: 1.0 In-Reply-To: <20170202200632.13992-1-tj@kernel.org> References: <20170202200632.13992-1-tj@kernel.org> From: Andy Lutomirski Date: Thu, 2 Feb 2017 13:32:19 -0800 Message-ID: Subject: Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode To: Tejun Heo , Linux API Cc: Li Zefan , Johannes Weiner , Peter Zijlstra , Ingo Molnar , Paul Turner , Mike Galbraith , "open list:CONTROL GROUP (CGROUP)" , "linux-kernel@vger.kernel.org" , kernel-team@fb.com, lvenanci@redhat.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 2, 2017 at 12:06 PM, Tejun Heo wrote: > Hello, > > This patchset implements cgroup v2 thread mode. It is largely based > on the discussions that we had at the plumbers last year. Here's the > rough outline. I like this, but I have some design questions: > > * Thread mode is explicitly enabled on a cgroup by writing "enable" > into "cgroup.threads" file. The cgroup shouldn't have any child > cgroups or enabled controllers. Why do you need to manually turn it on? That is, couldn't it be automatic based on what controllers are enabled? > > * Once enabled, arbitrary sub-hierarchy can be created and threads can > be put anywhere in the subtree by writing TIDs into "cgroup.threads" > file. Process granularity and no-internal-process constraint don't > apply in a threaded subtree. I'm a bit worried that this conflates two different things. There's thread support, i.e. allowing individual threads to be placed into cgroups. There's also more flexible sub-hierarchy support, i.e. relaxing no-internal-process constraints. For the "cpuacct" controller, for example, both of these make sense. But what if someone writes a controller (directio, for example, just to make something up) for which thread granularity makes sense but relaxing no-internal-process constraints does not? --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode Date: Thu, 2 Feb 2017 13:32:19 -0800 Message-ID: References: <20170202200632.13992-1-tj@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20170202200632.13992-1-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Tejun Heo , Linux API Cc: Li Zefan , Johannes Weiner , Peter Zijlstra , 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 2, 2017 at 12:06 PM, Tejun Heo wrote: > Hello, > > This patchset implements cgroup v2 thread mode. It is largely based > on the discussions that we had at the plumbers last year. Here's the > rough outline. I like this, but I have some design questions: > > * Thread mode is explicitly enabled on a cgroup by writing "enable" > into "cgroup.threads" file. The cgroup shouldn't have any child > cgroups or enabled controllers. Why do you need to manually turn it on? That is, couldn't it be automatic based on what controllers are enabled? > > * Once enabled, arbitrary sub-hierarchy can be created and threads can > be put anywhere in the subtree by writing TIDs into "cgroup.threads" > file. Process granularity and no-internal-process constraint don't > apply in a threaded subtree. I'm a bit worried that this conflates two different things. There's thread support, i.e. allowing individual threads to be placed into cgroups. There's also more flexible sub-hierarchy support, i.e. relaxing no-internal-process constraints. For the "cpuacct" controller, for example, both of these make sense. But what if someone writes a controller (directio, for example, just to make something up) for which thread granularity makes sense but relaxing no-internal-process constraints does not? --Andy