Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp907056imp; Wed, 20 Feb 2019 11:11:56 -0800 (PST) X-Google-Smtp-Source: AHgI3IaQEoqEhvdXd55t/56JFWn+OkhkXqIpdqoUBCs+PFimv9nHN72UaW2D7k1X8Yx0KenL7ZgD X-Received: by 2002:a17:902:112c:: with SMTP id d41mr38280094pla.177.1550689916785; Wed, 20 Feb 2019 11:11:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550689916; cv=none; d=google.com; s=arc-20160816; b=tu3NbIfDaxWXF65rULzCPC7UQBo9/S20/OZGO8rWygkt6AoXNXuRkMChByBXdwy53m AeEWeeNUSUJDUXe11NPSuXBndN/5QGd8BBDidhD9VjlslF9tv0uqmmxeaV2Ll/sGgfCU 0Qa+vikOFPO3bIPy9k7VJ9orQIT4dAZhcKzA3QAm2D5eflbm4Cum4USHq9CrLYIv1auB UjtS6aWPrm4WNM7h8x5i9L3s2Hga3QMevrOk9CybDXUzd8aR45pAnR2SETDcIbWV7YRo KJaFB5/1ogvV5zMnk1qO4fC6cqQVSpHhEf7QCahZ78GJz6g6lWtyJmxH+FYjL/0VcONB sGuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=MNpG+7NE9CEwZpRcZsJF4M7fn6beDt1lJ2hBws3hS4o=; b=iHtQFTndhB+gYFMQ4tCX9/pvomDI23tAYci+0C261aEs/4/Rn0GfGsV5dTlRf8MsXE vhAQgnNrIrE03gAU/Ya68q5CyoNg8xZ2FqlL1+018hTGqCNAkCxSg2+H25ZDnqOgFcP0 DyjrxDKTIoQsTz9W6cUhU06u1cKtlVAjnRybilcbnMVyQsq8Ot/raFfkz6bszPRqaokR /7N/WeQmlZ0MpRiAbjJ92JE0fAFw2rWRp5Gq4K/M4vk30ofiyrxHO4txixbwkGXw49Ir eTiGskBXgq9ctokpZ35QuR8bzUXAmWm4D7DJH/TxfnxyGwURrlMEBO065y1JUM0KZJ8K ATmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@kerrnel.com header.s=default header.b=gN7Cci8h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v11si17324015pgb.276.2019.02.20.11.11.39; Wed, 20 Feb 2019 11:11:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@kerrnel.com header.s=default header.b=gN7Cci8h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726012AbfBTTLQ (ORCPT + 99 others); Wed, 20 Feb 2019 14:11:16 -0500 Received: from ch14b.valcato.com ([216.104.44.82]:42236 "EHLO ch14b.valcato.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725804AbfBTTLQ (ORCPT ); Wed, 20 Feb 2019 14:11:16 -0500 X-Greylist: delayed 2232 seconds by postgrey-1.27 at vger.kernel.org; Wed, 20 Feb 2019 14:11:16 EST DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kerrnel.com ; s=default; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MNpG+7NE9CEwZpRcZsJF4M7fn6beDt1lJ2hBws3hS4o=; b=gN7Cci8hHQYlI6NRwdHowWerLo +nC5t7Yfp68KJtJS9uh0GxuKe1WbwND5zTkID17JM1oW/e5RP0E9KBl3XCQzpUxAdM2BF7IlbXdyY 0TPRRTglAV9T6erX9M2GmrWoHCSAW7M4KiUL0Wet0vMHnSODF1xZGBaOW9zYCYnNPQHNEK7ipMQKZ V/KyT1s2Okp/xO8ZkXt2Ag8Zgxx6LO57cN3G9dT9mM48OpDFUT6W3v/0et4vHaj58wLAuUDMMUX0c r9dPVWk0xlhbfquj6Xvsa1rGGtyNaAhLaJd71tqPf26y81Rk3FJdu1v32RP3cBUZ1WGoW46hjjOnW mutgr0Nw==; Received: from [104.132.11.80] (port=62947 helo=kerrnel.com) by ch14b.valcato.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gwWgv-00Gmi2-Qn; Wed, 20 Feb 2019 18:33:58 +0000 Date: Wed, 20 Feb 2019 10:33:55 -0800 From: Greg Kerr To: Peter Zijlstra Cc: Greg Kerr , mingo@kernel.org, tglx@linutronix.de, Paul Turner , tim.c.chen@linux.intel.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, subhra.mazumdar@oracle.com, fweisbec@gmail.com, keescook@chromium.org Subject: Re: [RFC][PATCH 00/16] sched: Core scheduling Message-ID: <20190220183355.GA213003@kerrnel.com> References: <20190218165620.383905466@infradead.org> <20190220094255.GE32494@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190220094255.GE32494@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ch14b.valcato.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kerrnel.com X-Get-Message-Sender-Via: ch14b.valcato.com: authenticated_id: greg@kerrnel.com X-Authenticated-Sender: ch14b.valcato.com: greg@kerrnel.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 20, 2019 at 10:42:55AM +0100, Peter Zijlstra wrote: > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > I am relieved to know that when my mail client embeds HTML tags into raw text, it will only be the second most annoying thing I've done on e-mail. Speaking of annoying things to do, sorry for switching e-mail addresses but this is easier to do from my personal e-mail. > On Tue, Feb 19, 2019 at 02:07:01PM -0800, Greg Kerr wrote: > > Thanks for posting this patchset Peter. Based on the patch titled, "sched: A > > quick and dirty cgroup tagging interface," I believe cgroups are used to > > define co-scheduling groups in this implementation. > > > > Chrome OS engineers (kerrnel@google.com, mpdenton@google.com, and > > palmer@google.com) are considering an interface that is usable by unprivileged > > userspace apps. cgroups are a global resource that require privileged access. > > Have you considered an interface that is akin to namespaces? Consider the > > following strawperson API proposal (I understand prctl() is generally > > used for process > > specific actions, so we aren't married to using prctl()): > > I don't think we're anywhere near the point where I care about > interfaces with this stuff. > > Interfaces are a trivial but tedious matter once the rest works to > satisfaction. > I agree that the API itself is a bit of a bike shedding and that's why I provided a strawperson proposal to highlight the desired properties. I do think the high level semantics are important to agree upon. Using cgroups could imply that a privileged user is meant to create and track all the core scheduling groups. It sounds like you picked cgroups out of ease of prototyping and not the specific behavior? > As it happens; there is actually a bug in that very cgroup patch that > can cause undesired scheduling. Try spotting and fixing that. > This is where I think the high level properties of core scheduling are relevant. I'm not sure what bug is in the existing patch, but it's hard for me to tell if the existing code behaves correctly without answering questions, such as, "Should processes from two separate parents be allowed to co-execute?" > Another question is if we want to be L1TF complete (and how strict) or > not, and if so, build the missing pieces (for instance we currently > don't kick siblings on IRQ/trap/exception entry -- and yes that's nasty > and horrible code and missing for that reason). > I assumed from the beginning that this should be safe across exceptions. Is there a mitigating reason that it shouldn't? > > So first; does this provide what we need? If that's sorted we can > bike-shed on uapi/abi. I agree on not bike shedding about the API, but can we agree on some of the high level properties? For example, who generates the core scheduling ids, what properties about them are enforced, etc.? Regards, Greg Kerr