Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp635828pxf; Thu, 8 Apr 2021 09:51:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmyxquOzK5gOPp1UysVgRwcnvgUrD6ol2ffixac//6bF3qSELBmyrrlex6rwtQ7BQrybIT X-Received: by 2002:a05:6402:4a:: with SMTP id f10mr12620596edu.85.1617900661257; Thu, 08 Apr 2021 09:51:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617900661; cv=none; d=google.com; s=arc-20160816; b=rK9COA/kfVmT6wfHuH4GcD/NiIUKJJzhNw73TJiYelQvgmjeeC//XeTSaodzgHPN5p WgYtqZHE45bOOgoOLRICWb1rMH6OkMlQYprjRLMG2Ha2F0QKRIfjouLwH79RTGfBWUse nZv27tlJ4vume7b/POQkxKhSZtiTCi3ue/t2axYYlo6YfvT5VFOeUbVGdZi/F/WJxnmO Z1oTuB1pnLCDO9lBQTIeUy63EJSRWmU3OdlhyvuxyTHZvSEttJ5RJ/kuTIRoLT0JQB8j o2zYFNu0CD8qQvhhZs9jRl23/gufgDl7xdIf0M6WudN11/bFiw18MNRB5nene6uX9MK4 LIHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=tLdMJ4vAhY0dljsEQkW3I5q8Gz/FHaM+IhXZFq9oiug=; b=M4uaTWG5L5MkUkeJPKcpD6yWS72eiH8kqkMo1NpbSPeoJBkSiFf8Ml/hHTT3QFTcty OfBd4DRjqHjD6T3W4ueeSpWzDVbMkZDGz/JDF6W+4mljWEIyBlE+mcmlJDNdJ5WBM830 +tzziy0SB1V8/kyP2EGQTDhCoTH5He2UxO0FhxlHFdNVj6SRvXHPEAU8r5p525n0UCx4 aM/YDW7veLpeJxfw+fQPICG82qzxSat6cA56Qy+na0DJIBraggVvgHlSj/wfn+C3atBi ELXe7eU4WzkH0w95xJ4qmB5y9ZQ0huMScI1bPWkGQsGX2wa/kbGSyi1+ujurHToF7d/b 5qFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=J9An1k+7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y20si3922415edv.428.2021.04.08.09.50.36; Thu, 08 Apr 2021 09:51:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=J9An1k+7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232471AbhDHQtP (ORCPT + 99 others); Thu, 8 Apr 2021 12:49:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232466AbhDHQtJ (ORCPT ); Thu, 8 Apr 2021 12:49:09 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38677C061760 for ; Thu, 8 Apr 2021 09:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=tLdMJ4vAhY0dljsEQkW3I5q8Gz/FHaM+IhXZFq9oiug=; b=J9An1k+7gAaK2KDmSD/xLD7jhh aavOX9ApkeGmz2kctpgBRIWSk98pKU7R7iqtdZ/Fsxs6pOXKVRasV249bkptfQ12mgegPp3+IMWmt /Lv6mfyojGt2HKK/zPWchAqbiHtWvftK6PXr0d4a22mrIvHwdmY02ttWSnsHYmjr84tkLnm6YNGRN ZNPeU2X1kuZ9lvhBh2pv7PHa5cSkIX0NBVvNuTM/dwhBIHY6GGw416dVYG3c1C7s9sDUoNWgu4lSq 3ZnM97jfln7KiWxeZpJrZfGHzQMvlHdBEbtCN8kfdoRZoUVOMEIQ4Wxy7tVfDOoFvvOrC/FTGvT9i oTkMMZhg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94 #2 (Red Hat Linux)) id 1lUXnx-00GXdG-3V; Thu, 08 Apr 2021 16:47:06 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 61F943001DB; Thu, 8 Apr 2021 18:46:30 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 5AA8E2BCD72D1; Thu, 8 Apr 2021 17:02:20 +0200 (CEST) Date: Thu, 8 Apr 2021 17:02:20 +0200 From: Peter Zijlstra To: Michal =?iso-8859-1?Q?Koutn=FD?= Cc: Tejun Heo , joel@joelfernandes.org, chris.hyser@oracle.com, joshdon@google.com, mingo@kernel.org, vincent.guittot@linaro.org, valentin.schneider@arm.com, mgorman@suse.de, linux-kernel@vger.kernel.org, tglx@linutronix.de, Christian Brauner , Zefan Li Subject: Re: [PATCH 0/9] sched: Core scheduling interfaces Message-ID: References: <20210401131012.395311786@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 08, 2021 at 03:25:52PM +0200, Michal Koutn? wrote: > On Wed, Apr 07, 2021 at 08:34:24PM +0200, Peter Zijlstra wrote: > > IMO as long as cgroups have that tasks file, you get to support people > > using it. That means that tasks joining your cgroup need to 'inherit' > > cgroup properties. > The tasks file is consequence of binding this to cgroups, I'm one step > back. Why to make "core isolation" a cgroup property? Yeah, dunno, people asked for it. I'm just proposing an implementation that, when given the need, seems to make sense and is internally consistent. > (I understand this could help "visualize" what the common domains are if > cgroups were the only API but with prctl the structure can be > arbitrarily modified anyway.) > > > > Given something like: > > > > R > > / \ > > A B > > / \ > > C D > Thanks for the example. > > > B group can set core_sched=1 and then all its (and its decendants) tasks > > get to have the same (group) cookie and cannot share with others. > The same could be achieved with the first task of group B allocating its > new cookie which would be inherited in its descednants. Except then the task can CLEAR its own cookie and escape the constraint. > > In that scenario the D subtree is a restriction (doesn't share) with the > > B subtree. > This implies D's isolation from everything else too, not just B's > members, no? Correct. Look at it as a contraint on co-scheduling, you can never, whatever you do, share an SMT sibling with someone outside your subtree. > > And all of B is a restriction on all its tasks, including the Real-Time > > task that set a task cookie, in that none of them can share with tasks > > outside of B (including system tasks which are in R), irrespective of > > what they do with their task cookie. > IIUC, the equivalent restriction could be achieved with the PTRACE-like > check in the prctl API too (with respectively divided uids). I'm not sure I understand; if tasks in A and B are of the same user, then ptrace will not help anything. And per the above, you always have ptrace on yourself so you can escape your constraint per the above. > I'm curious whether the cgroup API actually simplifies things that are > possible with the clone/prctl API or allows anything that wouldn't be > otherwise possible. With the cgroup API it is impossible for a task to escape the cgroup constraint. It can never share a core with anything not in the subtree. This is not possible with just the task interface. If this is actually needed I've no clue, IMO all of cgroups is not needed :-) Clearly other people feel differently about that. Much of this would go away if CLEAR were not possible I suppose. But IIRC the idea was to let a task isolate itself temporarily, while doing some sensitive thing (eg. encrypt an email) but otherwise not be constrained. But I'm not sure I can remember all the various things people wanted this crud for :/