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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1B9AC433FE for ; Wed, 5 Oct 2022 15:31:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230281AbiJEPbe (ORCPT ); Wed, 5 Oct 2022 11:31:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229819AbiJEPbb (ORCPT ); Wed, 5 Oct 2022 11:31:31 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 48F201A078 for ; Wed, 5 Oct 2022 08:31:30 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 913D9113E; Wed, 5 Oct 2022 08:31:36 -0700 (PDT) Received: from wubuntu (unknown [10.57.32.122]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 89D5F3F67D; Wed, 5 Oct 2022 08:31:27 -0700 (PDT) Date: Wed, 5 Oct 2022 16:31:25 +0100 From: Qais Yousef To: John Stultz Cc: LKML , Connor O'Brien , John Dias , Rick Yiu , John Kacur , Chris Redpath , Abhijeet Dharmapurikar , Peter Zijlstra , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Thomas Gleixner , kernel-team@android.com, "J . Avila" Subject: Re: [RFC PATCH v3 2/3] sched: Avoid placing RT threads on cores handling long softirqs Message-ID: <20221005153125.3apfpzhqs3mx6deg@wubuntu> References: <20220921012550.3288570-1-jstultz@google.com> <20220921012550.3288570-3-jstultz@google.com> <20220928125517.ei64pxfucaem55cr@wubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/03/22 09:55, John Stultz wrote: [...] > > > int target = find_lowest_rq(p); > > > @@ -1656,11 +1699,14 @@ select_task_rq_rt(struct task_struct *p, int cpu, int flags) > > > goto out_unlock; > > > > > > /* > > > - * Don't bother moving it if the destination CPU is > > > + * If cpu is non-preemptible, prefer remote cpu > > > + * even if it's running a higher-prio task. > > > + * Otherwise: Don't bother moving it if the destination CPU is > > > * not running a lower priority task. > > > */ > > > if (target != -1 && > > > - p->prio < cpu_rq(target)->rt.highest_prio.curr) > > > + (may_not_preempt || > > > + p->prio < cpu_rq(target)->rt.highest_prio.curr)) > > > cpu = target; > > > > I'm not sure this makes sense. You assume a higher priority task will cause > > less delay than softirqs. Which I think is an optimistic assumption? > > > > I think we should just mimic the same fallback behavior when we fail to find > > a CPU that fits the capacity requirement. Keeps things more consistent IMO. > > This sounds reasonable. I do fret that long-running rt tasks are less > common then the long running softirqs, so this may have an impact to > the effectiveness of the patch, but I also suspect it's even more rare > to have all the other cpus busy with rt tasks, so its probably very > unlikely. Yes. I think it is a hard problem to hit as all these other RT tasks must be higher priority. So if this ever happens, then one should question if the priority is set correctly for the audio threads first. Or why there are so many higher priority tasks running for so long. Thanks! -- Qais Yousef