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=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 1B258C432BE for ; Wed, 18 Aug 2021 10:42:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 026DB60FE6 for ; Wed, 18 Aug 2021 10:42:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234601AbhHRKnL (ORCPT ); Wed, 18 Aug 2021 06:43:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:48544 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233902AbhHRKnJ (ORCPT ); Wed, 18 Aug 2021 06:43:09 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CB2F060F58; Wed, 18 Aug 2021 10:42:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629283355; bh=bbi6ktG6FrjFoI+90EdyKoJgarLRcDLvzTOS9lfuw1s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tC55WRQxaYOwDkc7ctK5plhM78JGMGTfr9di/SZkM5GADwqyLsyKiSrVo5DW7Z+lc 6E30EFa/oHIg7pWInfHsAHWMBe9UIWPAaewLNWVRvEIe1RBSjPOzdmX9Dlt7R+++dm LebXqn1mqc/W/SliTJWX2U3yzHwbfWnAMP0ymPyo9ibACWlTLu1YJ4B+jiCpR8fePw ktCF/14EYBZbw8opPPZc7qIxOBH5Y/GMmwOcoLZpXCZHhSrINOt7rxsFws8HabCuTp VP0i9ao90A+gZcInxKjBR5Kdt9r3sXBC0dK82DgpmUTu6C5dyBA0xqe4lh9ltKIqSo k4GVd0aK1d/Qg== Date: Wed, 18 Aug 2021 11:42:28 +0100 From: Will Deacon To: Peter Zijlstra Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , Greg Kroah-Hartman , Morten Rasmussen , Qais Yousef , Suren Baghdasaryan , Quentin Perret , Tejun Heo , Johannes Weiner , Ingo Molnar , Juri Lelli , Vincent Guittot , "Rafael J. Wysocki" , Dietmar Eggemann , Daniel Bristot de Oliveira , Valentin Schneider , Mark Rutland , kernel-team@android.com Subject: Re: [PATCH v11 08/16] sched: Allow task CPU affinity to be restricted on asymmetric systems Message-ID: <20210818104227.GA13828@willie-the-truck> References: <20210730112443.23245-1-will@kernel.org> <20210730112443.23245-9-will@kernel.org> 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 Peter, On Tue, Aug 17, 2021 at 05:10:53PM +0200, Peter Zijlstra wrote: > On Fri, Jul 30, 2021 at 12:24:35PM +0100, Will Deacon wrote: > > @@ -2783,20 +2778,173 @@ static int __set_cpus_allowed_ptr(struct task_struct *p, > > > > __do_set_cpus_allowed(p, new_mask, flags); > > > > - return affine_move_task(rq, p, &rf, dest_cpu, flags); > > + if (flags & SCA_USER) > > + release_user_cpus_ptr(p); > > + > > + return affine_move_task(rq, p, rf, dest_cpu, flags); > > > > out: > > - task_rq_unlock(rq, p, &rf); > > + task_rq_unlock(rq, p, rf); > > > > return ret; > > } > > > +void relax_compatible_cpus_allowed_ptr(struct task_struct *p) > > +{ > > + unsigned long flags; > > + struct cpumask *mask = p->user_cpus_ptr; > > + > > + /* > > + * Try to restore the old affinity mask. If this fails, then > > + * we free the mask explicitly to avoid it being inherited across > > + * a subsequent fork(). > > + */ > > + if (!mask || !__sched_setaffinity(p, mask)) > > + return; > > + > > + raw_spin_lock_irqsave(&p->pi_lock, flags); > > + release_user_cpus_ptr(p); > > + raw_spin_unlock_irqrestore(&p->pi_lock, flags); > > +} > > Both these are a problem on RT. Ah, sorry. I didn't realise you couldn't _free_ with a raw lock held in RT. Is there somewhere I can read up on that? > The easiest recourse is simply never freeing the CPU mask (except on > exit). The alternative is something like the below I suppose.. > > I'm leaning towards the former option, wdyt? Defering the freeing until exit feels like a little fiddly, as we still want to clear ->user_cpus_ptr on affinity changes when SCA_USER is set so we'd have to keep track of the mask somewhere and reuse it instead of allocating a new one if we need it later on. Do-able, but feels a bit nasty, particular across fork(). As for your other suggestion: > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -2733,6 +2733,7 @@ static int __set_cpus_allowed_ptr_locked > const struct cpumask *cpu_allowed_mask = task_cpu_possible_mask(p); > const struct cpumask *cpu_valid_mask = cpu_active_mask; > bool kthread = p->flags & PF_KTHREAD; > + struct cpumask *user_mask = NULL; > unsigned int dest_cpu; > int ret = 0; > > @@ -2792,9 +2793,13 @@ static int __set_cpus_allowed_ptr_locked > __do_set_cpus_allowed(p, new_mask, flags); > > if (flags & SCA_USER) > - release_user_cpus_ptr(p); > + swap(user_mask, p->user_cpus_ptr); > + > + ret = affine_move_task(rq, p, rf, dest_cpu, flags); > + > + kfree(user_mask); > > - return affine_move_task(rq, p, rf, dest_cpu, flags); > + return ret; > > out: > task_rq_unlock(rq, p, rf); > @@ -2954,8 +2959,10 @@ void relax_compatible_cpus_allowed_ptr(s > return; > > raw_spin_lock_irqsave(&p->pi_lock, flags); > - release_user_cpus_ptr(p); > + p->user_cpus_ptr = NULL; > raw_spin_unlock_irqrestore(&p->pi_lock, flags); > + > + kfree(mask); I think the idea looks good, but perhaps we could wrap things up a bit: /* Comment about why this is useful with RT */ static cpumask_t *clear_user_cpus_ptr(struct task_struct *p) { struct cpumask *user_mask = NULL; swap(user_mask, p->user_cpus_ptr); return user_mask; } void release_user_cpus_ptr(struct task_struct *p) { kfree(clear_user_cpus_ptr(p)); } Then just use clear_user_cpus_ptr() in sched/core.c where we know what we're doing (well, at least one of us does!). 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=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 6E263C4338F for ; Wed, 18 Aug 2021 10:44:36 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 3BA5060FE6 for ; Wed, 18 Aug 2021 10:44:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3BA5060FE6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=0NsAjIxoA8QjDPFX17L3bHnTkJLPY3Knli5FAh4ebMQ=; b=aUUVPgnPztCcTx DAtHXUK5lT781iJGq4ybGxSg2Xi7Ku8MFFMnPjeheOcbstl4cswIpIo4xv/UGd06FU5OLL7SPdbkH jy4h9/+fEBfF4jGsYbvaAd/BbL4TFaI8YJrMUq8vibtkumgRKYYqqfIhLbPqnmFru21m5Nbzu+mY7 Q4zEe9JG5ah0eCtjCCbr/uCBr15UzeBOGY4oRroWz4cVhszoBOIcnBZUnk5qkmyzspkLxRp8rsHEb Vu40/BbwzMAKIm7V+oBzsJUbhe2x9z+ILgvYS7FDz3zQPrRZMEMqF3wzKUHK8WvHmDX5XSuHw74Xa 4CS0SwCyqL46STHhWA/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGJ1z-005CmN-E5; Wed, 18 Aug 2021 10:42:47 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGJ1o-005Cjs-3V for linux-arm-kernel@lists.infradead.org; Wed, 18 Aug 2021 10:42:40 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id CB2F060F58; Wed, 18 Aug 2021 10:42:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629283355; bh=bbi6ktG6FrjFoI+90EdyKoJgarLRcDLvzTOS9lfuw1s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tC55WRQxaYOwDkc7ctK5plhM78JGMGTfr9di/SZkM5GADwqyLsyKiSrVo5DW7Z+lc 6E30EFa/oHIg7pWInfHsAHWMBe9UIWPAaewLNWVRvEIe1RBSjPOzdmX9Dlt7R+++dm LebXqn1mqc/W/SliTJWX2U3yzHwbfWnAMP0ymPyo9ibACWlTLu1YJ4B+jiCpR8fePw ktCF/14EYBZbw8opPPZc7qIxOBH5Y/GMmwOcoLZpXCZHhSrINOt7rxsFws8HabCuTp VP0i9ao90A+gZcInxKjBR5Kdt9r3sXBC0dK82DgpmUTu6C5dyBA0xqe4lh9ltKIqSo k4GVd0aK1d/Qg== Date: Wed, 18 Aug 2021 11:42:28 +0100 From: Will Deacon To: Peter Zijlstra Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas , Marc Zyngier , Greg Kroah-Hartman , Morten Rasmussen , Qais Yousef , Suren Baghdasaryan , Quentin Perret , Tejun Heo , Johannes Weiner , Ingo Molnar , Juri Lelli , Vincent Guittot , "Rafael J. Wysocki" , Dietmar Eggemann , Daniel Bristot de Oliveira , Valentin Schneider , Mark Rutland , kernel-team@android.com Subject: Re: [PATCH v11 08/16] sched: Allow task CPU affinity to be restricted on asymmetric systems Message-ID: <20210818104227.GA13828@willie-the-truck> References: <20210730112443.23245-1-will@kernel.org> <20210730112443.23245-9-will@kernel.org> 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-20210818_034236_295039_E724D404 X-CRM114-Status: GOOD ( 25.96 ) 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 Peter, On Tue, Aug 17, 2021 at 05:10:53PM +0200, Peter Zijlstra wrote: > On Fri, Jul 30, 2021 at 12:24:35PM +0100, Will Deacon wrote: > > @@ -2783,20 +2778,173 @@ static int __set_cpus_allowed_ptr(struct task_struct *p, > > > > __do_set_cpus_allowed(p, new_mask, flags); > > > > - return affine_move_task(rq, p, &rf, dest_cpu, flags); > > + if (flags & SCA_USER) > > + release_user_cpus_ptr(p); > > + > > + return affine_move_task(rq, p, rf, dest_cpu, flags); > > > > out: > > - task_rq_unlock(rq, p, &rf); > > + task_rq_unlock(rq, p, rf); > > > > return ret; > > } > > > +void relax_compatible_cpus_allowed_ptr(struct task_struct *p) > > +{ > > + unsigned long flags; > > + struct cpumask *mask = p->user_cpus_ptr; > > + > > + /* > > + * Try to restore the old affinity mask. If this fails, then > > + * we free the mask explicitly to avoid it being inherited across > > + * a subsequent fork(). > > + */ > > + if (!mask || !__sched_setaffinity(p, mask)) > > + return; > > + > > + raw_spin_lock_irqsave(&p->pi_lock, flags); > > + release_user_cpus_ptr(p); > > + raw_spin_unlock_irqrestore(&p->pi_lock, flags); > > +} > > Both these are a problem on RT. Ah, sorry. I didn't realise you couldn't _free_ with a raw lock held in RT. Is there somewhere I can read up on that? > The easiest recourse is simply never freeing the CPU mask (except on > exit). The alternative is something like the below I suppose.. > > I'm leaning towards the former option, wdyt? Defering the freeing until exit feels like a little fiddly, as we still want to clear ->user_cpus_ptr on affinity changes when SCA_USER is set so we'd have to keep track of the mask somewhere and reuse it instead of allocating a new one if we need it later on. Do-able, but feels a bit nasty, particular across fork(). As for your other suggestion: > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -2733,6 +2733,7 @@ static int __set_cpus_allowed_ptr_locked > const struct cpumask *cpu_allowed_mask = task_cpu_possible_mask(p); > const struct cpumask *cpu_valid_mask = cpu_active_mask; > bool kthread = p->flags & PF_KTHREAD; > + struct cpumask *user_mask = NULL; > unsigned int dest_cpu; > int ret = 0; > > @@ -2792,9 +2793,13 @@ static int __set_cpus_allowed_ptr_locked > __do_set_cpus_allowed(p, new_mask, flags); > > if (flags & SCA_USER) > - release_user_cpus_ptr(p); > + swap(user_mask, p->user_cpus_ptr); > + > + ret = affine_move_task(rq, p, rf, dest_cpu, flags); > + > + kfree(user_mask); > > - return affine_move_task(rq, p, rf, dest_cpu, flags); > + return ret; > > out: > task_rq_unlock(rq, p, rf); > @@ -2954,8 +2959,10 @@ void relax_compatible_cpus_allowed_ptr(s > return; > > raw_spin_lock_irqsave(&p->pi_lock, flags); > - release_user_cpus_ptr(p); > + p->user_cpus_ptr = NULL; > raw_spin_unlock_irqrestore(&p->pi_lock, flags); > + > + kfree(mask); I think the idea looks good, but perhaps we could wrap things up a bit: /* Comment about why this is useful with RT */ static cpumask_t *clear_user_cpus_ptr(struct task_struct *p) { struct cpumask *user_mask = NULL; swap(user_mask, p->user_cpus_ptr); return user_mask; } void release_user_cpus_ptr(struct task_struct *p) { kfree(clear_user_cpus_ptr(p)); } Then just use clear_user_cpus_ptr() in sched/core.c where we know what we're doing (well, at least one of us does!). Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel