From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73276C433B4 for ; Thu, 20 May 2021 11:47:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 518986101E for ; Thu, 20 May 2021 11:47:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242931AbhETLsk (ORCPT ); Thu, 20 May 2021 07:48:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:45836 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241733AbhETLZZ (ORCPT ); Thu, 20 May 2021 07:25:25 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C3B0F61441; Thu, 20 May 2021 10:16:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621505807; bh=CNpVJE3RYe0c2aFu09c+Q6PiGWS30OlaJEezwJN5FyA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FrifPBqYl97wkhjbu0C1WYT9XYbJjq+dXoI+goHcgUxbOBMCkgHSIsisXCGHCOd+V 9/uDX4pWVsJ7/4gWYua6WQVnoGsvGfjpiyHgLrip0Ay+I2hEeUhPlS6eg4DN/EJcxP 7rZmpiAAd+XuFWzPCOjETwtSjwyDHowF/0jg6o/bLN33iPLVZ7ifjVWL7eGyMgWbyt oDr4uaXemk29XsbKlTVtc3nYo5ab8p8pKnb1b4DPU9ROo8CkEhsClmJQMjC0CVZSeR CO3xRolOhRwpZF5fbmXPQnseN22EwZ7LRA/n9nJ8q3Bjefs1a5XEKGQQ9Tmct08R1F 22q60Emo0Zkqw== Date: Thu, 20 May 2021 11:16:41 +0100 From: Will Deacon To: Juri Lelli Cc: Quentin Perret , linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , Greg Kroah-Hartman , Peter Zijlstra , Morten Rasmussen , Qais Yousef , Suren Baghdasaryan , Tejun Heo , Johannes Weiner , Ingo Molnar , Vincent Guittot , "Rafael J. Wysocki" , kernel-team@android.com, Daniel Bristot de Oliveira Subject: Re: [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE Message-ID: <20210520101640.GA10065@willie-the-truck> References: <20210518094725.7701-1-will@kernel.org> <20210518094725.7701-14-will@kernel.org> <20210518102833.GA7770@willie-the-truck> <20210518105951.GC7770@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Juri, On Thu, May 20, 2021 at 11:13:39AM +0200, Juri Lelli wrote: > Apologies for the delay in replying. Not at all! > On 18/05/21 13:19, Quentin Perret wrote: > > On Tuesday 18 May 2021 at 11:59:51 (+0100), Will Deacon wrote: > > > On Tue, May 18, 2021 at 10:48:07AM +0000, Quentin Perret wrote: > > > > On Tuesday 18 May 2021 at 11:28:34 (+0100), Will Deacon wrote: > > > > > I don't have strong opinions on this, but I _do_ want the admission via > > > > > sched_setattr() to be consistent with execve(). What you're suggesting > > > > > ticks that box, but how many applications are prepared to handle a failed > > > > > execve()? I suspect it will be fatal. > > > > > > > > Yep, probably. > > > > > > > > > Probably also worth pointing out that the approach here will at least > > > > > warn in the execve() case when the affinity is overridden for a deadline > > > > > task. > > > > > > > > Right so I think either way will be imperfect, so I agree with the > > > > above. > > > > > > > > Maybe one thing though is that, IIRC, userspace _can_ disable admission > > > > control if it wants to. In this case I'd have no problem with allowing > > > > this weird behaviour when admission control is off -- the kernel won't > > > > provide any guarantees. But if it's left on, then it's a different > > > > story. > > > > > > > > So what about we say, if admission control is off, we allow execve() and > > > > sched_setattr() with appropriate warnings as you suggest, but if > > > > admission control is on then we fail both? > > > > > > That's an interesting idea. The part that I'm not super keen about is > > > that it means admission control _also_ has an effect on the behaviour of > > > execve() > > > > Right, that's a good point. And it looks like fork() behaves the same > > regardless of admission control being enabled or not -- it is forbidden > > from DL either way. So I can't say there is a precedent :/ > > > > > so practically you'd have to have it disabled as long as you > > > have the possibility of 32-bit deadline tasks anywhere in the system, > > > which impacts 64-bit tasks which may well want admission control enabled. > > > > Indeed, this is a bit sad, but I don't know if the kernel should pretend > > it can guarantee to meet your deadlines and at the same time allow to do > > something that wrecks the underlying theory. > > > > I'd personally be happy with saying that admission control should be > > disabled on these dumb systems (and have that documented), at least > > until DL gets proper support for affinities. ISTR there was work going > > in that direction, but some folks in the CC list will know better. > > > > @Juri, maybe you would know if that's still planned? > > I won't go as far as saying planned, but that is still under "our" radar > for sure. Daniel was working on it, but I don't think he had any time to > resume that bit of work lately. > > So, until we have that, I think we have been as conservative as we could > for this type of decisions. I'm a little afraid that allowing > configuration to break admission control (even with a non fatal warning > is emitted) is still risky. I'd go with fail hard if AC is on, let it > pass if AC is off (supposedly the user knows what to do). But I'm not > familiar with the mixed 32/64 apps usecase you describe, so I might be > missing details. Ok, thanks for the insight. In which case, I'll go with what we discussed: require admission control to be disabled for sched_setattr() but allow execve() to a 32-bit task from a 64-bit deadline task with a warning (this is probably similar to CPU hotplug?). I'll update that for v8, and this patch will disappear. Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F753C433B4 for ; Thu, 20 May 2021 10:18:32 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DE08461074 for ; Thu, 20 May 2021 10:18:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DE08461074 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z7U/Y6zKdVpBGoep8+kJn53QwiGKKxojFrJoruWbeRM=; b=Xqzy4JIc3CeKcAeM+WYp0Z6tqK DTLQHawYY6ObVGUr2uLXZ4341hwTpKTEAQq2ZtAvW0D/mYCfQkpA3sPbjcCGFA0nMvMQ9kAos7K2H Y+mqqYTVJ3Hec5fUJXp/iVU2W1kMfU7jewrd11Cm1OmyF++cW16XuHbWh/DsWy3kXYib5eZ6+ALgS B2cLELwP+my6gpcBn/AdfJjJB7rcgiju3ixBSJxLLFGciqLRQlpabKXyt0asKboB4UjvXORnWqN6n e08FZ+SkUEaBclJWw/ZcexGnHXpVw+nkr8DfGv+4AbiDEykAww6Cx5Gkhd5R6hdss5XcVlvSigvV2 NchpVAOw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ljfjc-0006JK-BI; Thu, 20 May 2021 10:16:56 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ljfjY-0006Iu-HS for linux-arm-kernel@desiato.infradead.org; Thu, 20 May 2021 10:16:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; 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; bh=4NZCWixzQa7XTSQr0EEJJAEFcKHgtCXI1R+MJCbyjHI=; b=HZHsFle54AEkRQZOZi/MDre3P4 1HpM/446dxURe87J1lUj1aNlaBpfFnwryKDeGcTu6JqY15n45zkDcd636tQWqTPrzSVIAep1wLN0J BbPh+6njq+YApo/i6Vz72NQUZ+VAujmPzs3gbxq0bWWoWrcfnvuhjt7mfiDs2iSew0jyE+JEWiYKp LKox7VJDPMOaC9Yh5+uO6/yROiRavxM2C5eeyz0GzL+Jn9j1JvCq3u/dsB/n/xrc82SYi6oOVqpzh MFnNhw95rnGsk8BKqzBN0E3BLGtJd06Ttxg1cUP7e5oRSrNq0IpJVSCdWju4tfuBUwbK62q8rU0qP AaSVXJew==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ljfjV-00G9ts-Ot for linux-arm-kernel@lists.infradead.org; Thu, 20 May 2021 10:16:51 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id C3B0F61441; Thu, 20 May 2021 10:16:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621505807; bh=CNpVJE3RYe0c2aFu09c+Q6PiGWS30OlaJEezwJN5FyA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FrifPBqYl97wkhjbu0C1WYT9XYbJjq+dXoI+goHcgUxbOBMCkgHSIsisXCGHCOd+V 9/uDX4pWVsJ7/4gWYua6WQVnoGsvGfjpiyHgLrip0Ay+I2hEeUhPlS6eg4DN/EJcxP 7rZmpiAAd+XuFWzPCOjETwtSjwyDHowF/0jg6o/bLN33iPLVZ7ifjVWL7eGyMgWbyt oDr4uaXemk29XsbKlTVtc3nYo5ab8p8pKnb1b4DPU9ROo8CkEhsClmJQMjC0CVZSeR CO3xRolOhRwpZF5fbmXPQnseN22EwZ7LRA/n9nJ8q3Bjefs1a5XEKGQQ9Tmct08R1F 22q60Emo0Zkqw== Date: Thu, 20 May 2021 11:16:41 +0100 From: Will Deacon To: Juri Lelli Cc: Quentin Perret , linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , Greg Kroah-Hartman , Peter Zijlstra , Morten Rasmussen , Qais Yousef , Suren Baghdasaryan , Tejun Heo , Johannes Weiner , Ingo Molnar , Vincent Guittot , "Rafael J. Wysocki" , kernel-team@android.com, Daniel Bristot de Oliveira Subject: Re: [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE Message-ID: <20210520101640.GA10065@willie-the-truck> References: <20210518094725.7701-1-will@kernel.org> <20210518094725.7701-14-will@kernel.org> <20210518102833.GA7770@willie-the-truck> <20210518105951.GC7770@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210520_031649_892825_CCF3CA3C X-CRM114-Status: GOOD ( 41.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Juri, On Thu, May 20, 2021 at 11:13:39AM +0200, Juri Lelli wrote: > Apologies for the delay in replying. Not at all! > On 18/05/21 13:19, Quentin Perret wrote: > > On Tuesday 18 May 2021 at 11:59:51 (+0100), Will Deacon wrote: > > > On Tue, May 18, 2021 at 10:48:07AM +0000, Quentin Perret wrote: > > > > On Tuesday 18 May 2021 at 11:28:34 (+0100), Will Deacon wrote: > > > > > I don't have strong opinions on this, but I _do_ want the admission via > > > > > sched_setattr() to be consistent with execve(). What you're suggesting > > > > > ticks that box, but how many applications are prepared to handle a failed > > > > > execve()? I suspect it will be fatal. > > > > > > > > Yep, probably. > > > > > > > > > Probably also worth pointing out that the approach here will at least > > > > > warn in the execve() case when the affinity is overridden for a deadline > > > > > task. > > > > > > > > Right so I think either way will be imperfect, so I agree with the > > > > above. > > > > > > > > Maybe one thing though is that, IIRC, userspace _can_ disable admission > > > > control if it wants to. In this case I'd have no problem with allowing > > > > this weird behaviour when admission control is off -- the kernel won't > > > > provide any guarantees. But if it's left on, then it's a different > > > > story. > > > > > > > > So what about we say, if admission control is off, we allow execve() and > > > > sched_setattr() with appropriate warnings as you suggest, but if > > > > admission control is on then we fail both? > > > > > > That's an interesting idea. The part that I'm not super keen about is > > > that it means admission control _also_ has an effect on the behaviour of > > > execve() > > > > Right, that's a good point. And it looks like fork() behaves the same > > regardless of admission control being enabled or not -- it is forbidden > > from DL either way. So I can't say there is a precedent :/ > > > > > so practically you'd have to have it disabled as long as you > > > have the possibility of 32-bit deadline tasks anywhere in the system, > > > which impacts 64-bit tasks which may well want admission control enabled. > > > > Indeed, this is a bit sad, but I don't know if the kernel should pretend > > it can guarantee to meet your deadlines and at the same time allow to do > > something that wrecks the underlying theory. > > > > I'd personally be happy with saying that admission control should be > > disabled on these dumb systems (and have that documented), at least > > until DL gets proper support for affinities. ISTR there was work going > > in that direction, but some folks in the CC list will know better. > > > > @Juri, maybe you would know if that's still planned? > > I won't go as far as saying planned, but that is still under "our" radar > for sure. Daniel was working on it, but I don't think he had any time to > resume that bit of work lately. > > So, until we have that, I think we have been as conservative as we could > for this type of decisions. I'm a little afraid that allowing > configuration to break admission control (even with a non fatal warning > is emitted) is still risky. I'd go with fail hard if AC is on, let it > pass if AC is off (supposedly the user knows what to do). But I'm not > familiar with the mixed 32/64 apps usecase you describe, so I might be > missing details. Ok, thanks for the insight. In which case, I'll go with what we discussed: require admission control to be disabled for sched_setattr() but allow execve() to a 32-bit task from a 64-bit deadline task with a warning (this is probably similar to CPU hotplug?). I'll update that for v8, and this patch will disappear. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel