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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E677BC433B4 for ; Tue, 18 May 2021 13:23:31 +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 661CA6008E for ; Tue, 18 May 2021 13:23:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 661CA6008E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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=NBZ2cjJ2EakJoypP7JvLJbzFeSsdc+sbjdMFp5K+kic=; b=e6Qq2aSwz5fa5NGBJO8sWkIhO 4WLLG4HPWv8nFn58kKUCkSBWL9TRbak3l3OPm7uVFO6qpcJztjX7eOUvzkznIGvXjosdv5x8Xti7y nJZH6hlhCsRyPqR9vKsXmH+M3VTdDEj60YvGEI++pb7g4cTIZxad+vYm5qQCaZ52CuEchyWgfnJXy l030diWxVKj4pK6J4itd81IITBMz2O6sa/b1NxxAUM/1b/dZijjB+PEleNg0hDzMWns7ipLmEZslY NRdyGnKFH6MfmT7nQy1Y5j1t4JK0D/nHIceEUVnLZ/RmTQ0Xwli8L7G4G1YDcyAI1SfDETq61waFe RdeF4IBRA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lizdk-000rTa-TG; Tue, 18 May 2021 13:20:05 +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 1lizdh-000rSI-2c for linux-arm-kernel@desiato.infradead.org; Tue, 18 May 2021 13:20:01 +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=Fl2hbnq4KTo11sm1rurPAiZ5nl2ffJf+gTd0frGhNMo=; b=AhmlMoynk05IncE5+W88nSSkYD qanw+WPBg1hZNO4NmrOo3oohSIAyjp+V0hRTFHMUtAGQLj+KeKwQRxu5tdNzAOiNfRKohGZFiaXs/ 8nO3x+DwNeNUqElDmUczPI5mz1H5T64huH1XWXOho3m3gytU8y3kqXiJOQsAhi990JDhLyJzCHctJ AmSKSaQxI8GLBiBlrApbK2dYRxycy0E3Zwmx2PxjFxb8jvbRIWnC4Dovtyw+dzEHfplyjrM0WYS5j LU0vQFGhOPDFQHWpaND2JghQiv8PsMBVeX0wuoTLBVtsCSMBM+3m+8rrziMGPQ3e3CJBOv9bFcYWQ wUd9F+Hg==; Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lizdc-00Eg5c-T0 for linux-arm-kernel@lists.infradead.org; Tue, 18 May 2021 13:19:59 +0000 Received: by mail-wr1-x436.google.com with SMTP id j14so8467171wrq.5 for ; Tue, 18 May 2021 06:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Fl2hbnq4KTo11sm1rurPAiZ5nl2ffJf+gTd0frGhNMo=; b=m5PLNpLU1FyFg7I9oj9BuALAC/QcWw5Dv8rvdXmUmFEOzVPqJWjuRNhWM1uIeiKauB 5CSLYCGqNyCCv6dV/WFrfWKU8lsgWPQySSv6artDRUhvhuVYinu6tdaHXBcqdiDOXr/e 3ZO/6MmqSw4OwF1PI3r7AZFvMyXuIpnhBOSuBY5u7AutQcyvyK2aLTnabPKr2U8rSq9E ma0YawdRqqf8fN8/3O7iHBKuA43jq2QBiwjKTGCOmB71PO2ua9kX2q1+RGwIJ7NFpQ05 85/jXgJA5boxxDLSGzic4iYHMnBeG9zYXW1VcckhRDuFfCswW2pUzfgAijFGfKUB2FDi IyuA== 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=Fl2hbnq4KTo11sm1rurPAiZ5nl2ffJf+gTd0frGhNMo=; b=RzDMXQX09Q5EEWM5Rhzczt1SvW7WWH/49oXz8oL4BS8GuYgwpEVSlNCTmwYEze7uqq PC00cq5A1vIPp8+7iv7OgOrLrfws7yq2znZI+Z6kbZgXSOhpY4KGUYHMl+5juSatbWGV us45YhDV/vjw1AeoiR1wQJb6wF4WjWQbgNupb/tco/HbImnjeKohUkMiMV+FB3SV2JJo QpfEEmgPEd8dfuIuIIKGg9XAPdmH9LBY2/3JrLk3MumqAosE6Gun+G7Mcl0XpOTDs+qN bBPR9ghvXspHgFIh4YmV7o23UQcf2f/MhfF4lsPGb/3RlVN7Jc6Ex7UIYqNZnd9zwghk rWaA== X-Gm-Message-State: AOAM531mnBbo5vVrrq7numZk4mxrzhj41JmI3p+aSczLrl/1wja/aoGD EOAfjo5n5pelzxCYd7WK7/MnJw== X-Google-Smtp-Source: ABdhPJwtEm2cBRiEIt+snvROWKnxUOfuHq73a7rNECr6Qw9eykwLa7rdlkW34cJYL3rFLTjdPydmaA== X-Received: by 2002:a5d:4910:: with SMTP id x16mr7053213wrq.112.1621343993969; Tue, 18 May 2021 06:19:53 -0700 (PDT) Received: from google.com (105.168.195.35.bc.googleusercontent.com. [35.195.168.105]) by smtp.gmail.com with ESMTPSA id x8sm21590597wrs.25.2021.05.18.06.19.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 May 2021 06:19:53 -0700 (PDT) Date: Tue, 18 May 2021 13:19:50 +0000 From: Quentin Perret To: Will Deacon 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: 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: <20210518105951.GC7770@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210518_061956_975125_F5177E02 X-CRM114-Status: GOOD ( 32.56 ) 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 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? Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel