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 0360AC433ED for ; Tue, 18 May 2021 11:01:48 +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 737A760FDA for ; Tue, 18 May 2021 11:01:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 737A760FDA 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=jBAHtqVecBRVfAJFDiD0phIBuI7kRQThWB7fNj1nSvo=; b=YMhbuZdsSYIGVpAg1S4ujFS4g Q+EQorXhlbk1wTpUDg+iQwonCutkJfjNAm6o/DlW4Zw/82CX9DJzPdopBvrw/bIy/k3C2OhcMa4/m AsmgVm/Vyeq98CmDsQ98wiAqfIV/2WmmDGn2CkA5hUvZTRVUOX1SQTqgyZZ4JECVECYJPl/YH64iq h45b3bDYgPyjAigODDRVkVjbEXKjX39VaDBi0/Whhrr6ORRWwMxq9oj+pqqeXD3kM1qfIlVM7dT4s /iEJe3hzCYLLeUyFGq8kZkYd94z/Xo8frFo/pjehAtWhiDouftMtZ7PE40AhEpkuXi5Z5/5gfG5bw Ua3LsPJnQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lixSM-000TVE-3C; Tue, 18 May 2021 11:00:10 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lixSE-000TU0-BU for linux-arm-kernel@desiato.infradead.org; Tue, 18 May 2021 11:00:02 +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=8lLpjLSTsHI4OkoHgEh0NL0Y7jaNgduFir7Zd97cQ9s=; b=F03IIKajeZpEa8xUm8jhzphbv3 JDRkwtWSDfuKr+LbfBzO8fUDtWSv5ujXz95FN+I560Ahjjj2e1NFcdIetJBotlwTq9LJxbm5GMtUP 8C+sU+pIu96jJUHIDUtoLYduEEolBRpyP0Zs9MzIBBcAON182AM3VMGHZt5fEirxZGZoNcszYF4NK tLJhG6Zyom4cuC6ESBh67Z7oAQ10MLRbh8jFkNVO0k9iy80nVQbYGP17irkw7uDsWSHl7+3qOMC0n BaPK8dB/kLxcP52L/iOjHFKiaALrQc5RSLx4E+AI3VbP1X9ZtZTi54asDkP34xFAwlkaUIeWnLbal LUhm5MRQ==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lixSA-00EaMv-FK for linux-arm-kernel@lists.infradead.org; Tue, 18 May 2021 11:00:01 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 345F661285; Tue, 18 May 2021 10:59:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621335598; bh=GAu4rojTdKt4OvWm/lfPAfaF+P0Bv2/Zuy8m9Dpr8Hc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nTvC5ILgSDMPBB8Q9/Fxmdl3wZl2k2z0lugQX1WTE6EO+qimQX0L2JoXL0BQ++6XT Rv2RQVPF0QOZxJsiIzJmcoIBI8/qdm6AxvyJExYfMwqoawA2Iqg74sZDL0ytyt5vDD HZa3gQhf2m+scTQtuvvpcDLjfUEdalI2Gov/1/rMQNQLu+aYInC5QOy7tb6qqyke6e R/A1hui4xM2JA4lki0nnUaiUaLWVQ8Q7xnGGSwdvkwIy3GW7xjbTUntn4dR3uOOg5j n63+dCR7pS6yDz6/NAXlT5KcX5jS93daKIuB34/x0mVvwiSKeixbtMpGuPxYm9CE6a q7IrFG7a2UZuA== Date: Tue, 18 May 2021 11:59:51 +0100 From: Will Deacon To: Quentin Perret Cc: 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 , Juri Lelli , Vincent Guittot , "Rafael J. Wysocki" , kernel-team@android.com Subject: Re: [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE Message-ID: <20210518105951.GC7770@willie-the-truck> References: <20210518094725.7701-1-will@kernel.org> <20210518094725.7701-14-will@kernel.org> <20210518102833.GA7770@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-20210518_035958_564885_C3906FE9 X-CRM114-Status: GOOD ( 20.72 ) 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 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(), 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. So perhaps my initial position of trying to keep sched_setattr() and execve() consistent with each other is flawed and actually we can say: * Disable admission control if you want to admit a 32-bit task explicitly via sched_setattr() * If a 64-bit deadline task execve()s a 32-bit program then we warn and override the affinity (i.e. you should avoid doing this if you care about the deadlines). That amounts to dropping this patch and tweaking the documentation. Dunno, what do you think? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel