Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp607706ybr; Fri, 22 May 2020 14:37:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwaI4GNcfN5U34CT47U/qnkCYKnJxafTuZl7WxnIH0cIzuEYMxnSLyOSzu8/VxEEo4ywrmt X-Received: by 2002:a17:906:2e4a:: with SMTP id r10mr10749823eji.116.1590183429890; Fri, 22 May 2020 14:37:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590183429; cv=none; d=google.com; s=arc-20160816; b=C+fXlgKKFR2rqb8uyQjXiXfRRBceX4npo9YsJol0SMvBGpAhhdg5dZjtX70sbiq4z4 OssnI63wlp/pH4FPcrzi08dTcd9pP9Zuq01FD/D1nk59Jeh2KAKgPf+6yA8wrXtUriAC R3q6xT1V5zZxQe49WDUQo4Ha0kJDmi1GMB8at9ODuOdWvnBBHnuamlGFtuhj7Xscq+8H 3O4R17IXVQj05D1tWCLxNtoCuv2GvOd9fL96khlc+slh34YeUvL4JPgWKGZfqaRedpzG VsD8oqh6qVY5dRs/2Ekvlv5M30zHSKv0Qn2ks2ztGYfCKs7nGjBwwwQdKVQOt4yF0Rlf IJLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=EuUZVbTif3KQTMtt1mwZXN/LBHx9eL4POQtyuv8bdnA=; b=pTwhpadQ+1DvWvTRWazaxxIovch3azcdSW2LlkfyfGInPmN+VG6KBSsaBAeYs3z6rX /1sZVMl3b7Y6DwJyE0fYGH1UwXHNdU/JmDi0k6JJyI5Ef3LzOjJt4DwVQCrHinWHn/47 6jJ4jZ5DPr6u+Yd3RF+O6NfZ4T2wHsSAoY6k4qiDyym2RyjJ8o0zuGjsZWG23sRZO1l2 Q1BnSyB4QahppU5E6VztDZxhOQaA9YeNy+8vlm1aP0mcC+wa2KWoJYcqqyoHB+dpEwm7 Ap0mlch83HQxphlRLTZ2/EyO8WQW+EUG4NjBDGNDdEtFgEaDdyVDxVzJIm2kHKZuvNNd 3lRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=JPQNbT6N; 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 bc18si5323706edb.558.2020.05.22.14.36.47; Fri, 22 May 2020 14:37:09 -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=@joelfernandes.org header.s=google header.b=JPQNbT6N; 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 S1731107AbgEVVf1 (ORCPT + 99 others); Fri, 22 May 2020 17:35:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731081AbgEVVf1 (ORCPT ); Fri, 22 May 2020 17:35:27 -0400 Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E55B8C061A0E for ; Fri, 22 May 2020 14:35:26 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id m44so9474449qtm.8 for ; Fri, 22 May 2020 14:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=EuUZVbTif3KQTMtt1mwZXN/LBHx9eL4POQtyuv8bdnA=; b=JPQNbT6Ni7OZV8qKbVNQLcMjnTzGnwPjU5KG7KgcIjKClsZWST+bh9K81Zr54rNKhm xsmCvVsQtMpftVrfyomb3fGA79Y7rYnOS2CIEpD68wHozmdcq9uBwpm4b5h7SCa8O/Nd 0WfIdkPbUQeD7XeYv0O/OIh+oIopfo7XT7LqM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=EuUZVbTif3KQTMtt1mwZXN/LBHx9eL4POQtyuv8bdnA=; b=bX4RRyQJ1D3SQ7EupXv5tQdPJIK/MJ2jFKkw2wtbvYh0++gmoWwp6WZiYjNfjNEXuW wvZodkWJ6ZdeusQ/iHz0wHtnqDfS9spUaSjFURcLTOlAnSIhWP39yHcIOU5J+HSUpC3B xB0v4GEX+gbhnfgMASUNC4R76WVaz40AKUzrOQDD/Ns9JLZTbV1luvxKqqXRpSkGQbxl 5yZFYmrkuS0k1fPvUzpwcPhYQ0rpxLaGDGjYKtIc3TNIbhh5GHl4CCB5bQ3RWWBrfHXW 0oHXfRUFfs2cDChUp+Gw550s+y/1GgAKBPU+PVIYR4Y/+mOuFYlj6hPHCoxakXRsO3dH g+nQ== X-Gm-Message-State: AOAM532N2xz3APmsO+LPCFUpLfQUfe05kNn3mrQ7PxN32gNGZbl6XlK2 peTCrfyAT+oiPF2trdKW1Bc5mw== X-Received: by 2002:ac8:36a3:: with SMTP id a32mr18242439qtc.196.1590183325989; Fri, 22 May 2020 14:35:25 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id u129sm7976590qkb.51.2020.05.22.14.35.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2020 14:35:24 -0700 (PDT) Date: Fri, 22 May 2020 17:35:24 -0400 From: Joel Fernandes To: Peter Zijlstra Cc: Nishanth Aravamudan , Julien Desfossez , Tim Chen , mingo@kernel.org, tglx@linutronix.de, pjt@google.com, torvalds@linux-foundation.org, vpillai , linux-kernel@vger.kernel.org, fweisbec@gmail.com, keescook@chromium.org, Phil Auld , Aaron Lu , Aubrey Li , aubrey.li@linux.intel.com, Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini Subject: Re: [PATCH RFC] sched: Add a per-thread core scheduling interface Message-ID: <20200522213524.GD213825@google.com> References: <20200520222642.70679-1-joel@joelfernandes.org> <20200521085122.GF325280@hirez.programming.kicks-ass.net> <20200521134705.GA140701@google.com> <20200522125905.GM325280@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200522125905.GM325280@hirez.programming.kicks-ass.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 22, 2020 at 02:59:05PM +0200, Peter Zijlstra wrote: [..] > > > It doens't allow tasks for form their own groups (by for example setting > > > the key to that of another task). > > > > So for this, I was thinking of making the prctl pass in an integer. And 0 > > would mean untagged. Does that sound good to you? > > A TID, I think. If you pass your own TID, you tag yourself as > not-sharing. If you tag yourself with another tasks's TID, you can do > ptrace tests to see if you're allowed to observe their junk. But that would require a bunch of tasks agreeing on which TID to tag with. For example, if 2 tasks tag with each other's TID, then they would have different tags and not share. What's wrong with passing in an integer instead? In any case, we would do the CAP_SYS_ADMIN check to limit who can do it. Also, one thing CGroup interface allows is an external process to set the cookie, so I am wondering if we should use sched_setattr(2) instead of, or in addition to, the prctl(2). That way, we can drop the CGroup interface completely. How do you feel about that? > > > It is also horribly ill defined what it means to 'enable', with whoem > > > is it allows to share a core. > > > > I couldn't parse this. Do you mean "enabling coresched does not make sense if > > we don't specify whom to share the core with?" > > As a corrolary yes. I mostly meant that a blanket 'enable' doesn't > specify a 'who' you're sharing your bits with. Yes, ok. I can reword the commit log a bit to make it more clear that we are specifying who we can share a core with. > > I was just trying to respect the functionality of the CGroup patch in the > > coresched series, after all a gentleman named Peter Zijlstra wrote that > > patch ;-) ;-). > > Yeah, but I think that same guy said that that was a shit interface and > only hacked up because it was easy :-) Fair enough :-) > > More seriously, the reason I did it this way is the prctl-tagging is a bit > > incompatible with CGroup tagging: > > > > 1. What happens if 2 tasks are in a tagged CGroup and one of them changes > > their cookie through prctl? Do they still remain in the tagged CGroup but are > > now going to not trust each other? Do they get removed from the CGroup? This > > is why I made the prctl fail with -EBUSY in such cases. > > > > 2. What happens if 2 tagged tasks with different cookies are added to a > > tagged CGroup? Do we fail the addition of the tasks to the group, or do we > > override their cookie (like I'm doing)? > > For #2 I think I prefer failure. > > But having the rationale spelled out in documentation (man-pages for > example) is important. If we drop the CGroup interface, this would avoid both #1 and #2. thanks, - Joel