From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756521Ab1JTKcQ (ORCPT ); Thu, 20 Oct 2011 06:32:16 -0400 Received: from casper.infradead.org ([85.118.1.10]:41798 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754575Ab1JTKcP (ORCPT ); Thu, 20 Oct 2011 06:32:15 -0400 Subject: Re: patch] cpusets, cgroups: disallow attaching kthreadd From: Peter Zijlstra To: David Rientjes Cc: Mike Galbraith , LKML , Tejun Heo , Li Zefan , Paul Menage In-Reply-To: References: <1316758874.7393.2.camel@marge.simson.net> <4E7C2E7F.40307@cn.fujitsu.com> <1316762345.8168.4.camel@marge.simson.net> <1316770936.6641.11.camel@marge.simson.net> <1316775204.7562.9.camel@marge.simson.net> <1316788392.6544.33.camel@marge.simson.net> <1318224892.6161.45.camel@marge.simson.net> <1318233815.6527.5.camel@marge.simson.net> <1318925436.9641.23.camel@marge.simson.net> <1318927355.21167.3.camel@twins> <1318927629.9641.27.camel@marge.simson.net> <1318928763.21167.5.camel@twins> <1318929825.9641.32.camel@marge.simson.net> <1318932693.6748.5.camel@marge.simson.net> <1319010659.29774.3.camel@twins> Content-Type: text/plain; charset="UTF-8" Date: Thu, 20 Oct 2011 12:32:07 +0200 Message-ID: <1319106727.8653.3.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2011-10-19 at 12:47 -0700, David Rientjes wrote: > On Wed, 19 Oct 2011, Peter Zijlstra wrote: > > > My thinking is that kthreadd is the mother of all kernel threads and the > > kernel assumes it can spawn kthreads without constraints, a valid > > assumption IMO. > > > > Cgroups don't necessarily imply constraints, And yet they're called: Control Groups.. > though, you could devise a > cgroup to just do monitoring or statistics tracking for an aggregate of > tasks and placing kthreadd in such a cgroup would make perfect sense > because then, since children are forked in the same cgroup, you can > monitor or gather statistics for all kthreads. This can be your only > cgroup on the system. I guess you could, but does it really make sense? Also, you could sort this by extending the cgroup interface to explicitly distinct between controllers and !controllers. > Cpusets, though, does imply cpu constraints, which is why we decline > PF_THREAD_BOUND threads from moving in the first place, which is the > source of Mike's issue. It's can_attach() function can explicitly decline > kthreadd as well since the cpu constraints of both types of threads should > never be altered by either cpusets or sched_setaffinity(). Yeah, and I'm saying we want to exclude _all_ controllers from placing constraints on kthreadd, even those that might not immediately break stuff.