Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp6000341rwb; Tue, 1 Aug 2023 10:45:27 -0700 (PDT) X-Google-Smtp-Source: APBJJlGFyeuZ3mJH8oHUCdk3dl6wMP5i+GJdJGFzxMhbHttsFuzj7rdsbwgLljHroB1LJZ2VX2JF X-Received: by 2002:aa7:c309:0:b0:522:3a1d:c233 with SMTP id l9-20020aa7c309000000b005223a1dc233mr4423386edq.11.1690911927420; Tue, 01 Aug 2023 10:45:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690911927; cv=none; d=google.com; s=arc-20160816; b=pVuzKKOYEeb3zos0iQ6/uj41koUproXdGf0fUsFpw1obYHvFKsJHUMEtH5zkt+XWbP Ce+s5UaBHpxHxjuFwKkrPeqNM3jhHIZve4hPvUreD5LXu+KLcXmXcLeMwkbMSta6NRx8 bS5Fcp8GyWSkwGBnUFhvmWvEE58OpYkGaYnH8Q+ArdorpJfNzhk0aY48ThVPnOy/4mDW rBL68jl+g2paFEXHpTTpU0bwlF4LUfM0Qost3yfH8kbDyCrkfR6rVbpm1s5Mbw0sh2bV PoSAmnagRHD0bIA1Lz1XUTaSq0GfA1WBl57BwkIuZzVQdnx9PKkMgy5/KlW8S/oke0HQ 1HDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:dkim-signature:dkim-signature:date; bh=e+Sq00pg9zX9idaJMZOXf7RcOUolfU9E1Ueldsmzb9U=; fh=k45dwNjkkv+NDC8x9cOmIerayLVio41WsA0BZQDJUGQ=; b=y/zDFad1EFQw/t03eTEzZ1ykFrqRoatq6XfuKkaMrASVmpvjtDi8i9X8qyzvV/3dcP oyV/4c9T/iYvpliq2qJjJZ+PxUOtkLwFko4S0CH+u2lNezqAnxkGEe3i5amA7bYkkAq1 jhk+cPoPLa8xz5QzrRYpZEfXdIr4TUq7ovWuB4O2NGp+UYiN0UIzM1RmLODfrYMhLHPZ xncnJ1sDLkuP3sIez7bHvQkzi4jYdHHFT5yeE8ZROoXp7+MZXYpI8QJHJqjZzuiYysMW S9xCcd+c/1rC8cLjfWOgviU2nqaTLTEqFHbScUFbIBRyaPEGVU4ogd6FQXAl//epxML/ LpQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=m6dH707a; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m9-20020aa7d349000000b0051da389c522si8481037edr.610.2023.08.01.10.45.02; Tue, 01 Aug 2023 10:45:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=m6dH707a; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233770AbjHAP07 (ORCPT + 99 others); Tue, 1 Aug 2023 11:26:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234093AbjHAP0z (ORCPT ); Tue, 1 Aug 2023 11:26:55 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 618551FEE for ; Tue, 1 Aug 2023 08:26:54 -0700 (PDT) Date: Tue, 1 Aug 2023 17:26:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1690903612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=e+Sq00pg9zX9idaJMZOXf7RcOUolfU9E1Ueldsmzb9U=; b=m6dH707acHOf42oeSBtli0Utksxr7hRisdSQmwFe+LZXavmDGKVXNgQ7Tt28USHHPTqv5J c0FGKtL1YytiJzHi5HrvCDq4Mlypd4B+jkfcASBnfsOkMsdOOLJJvSqcAD6c5P8mu63lD2 NpusIGZso7La9OyrJQAHZo7C55thdVDVU0qjkQX0gObxPr+YnbKX1sJNpEJurPrwpxAhY5 n4NyC1g5C6yetQEXav9CqzUWfHOCaBVCeh/JVdRBHk3KdC0Su2JqwZGrZ7NOaqppf+l/6Y uScpI44f+ImvcQRegaj6aEIEDUdTCEhiq7BBcALl267aCrwS6Cm+kuxyPWhWdg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1690903612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=e+Sq00pg9zX9idaJMZOXf7RcOUolfU9E1Ueldsmzb9U=; b=QUXYg22OzS/BcPddjpaHBk91+eddU+p16HvAsQwa7jCVN+oyWZJXsJWc1dolmhnvSyKdXd 78s4JulygIRG2qDw== From: Sebastian Andrzej Siewior To: linux-kernel@vger.kernel.org Cc: Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Ingo Molnar , Juri Lelli , Mel Gorman , Peter Zijlstra , Steven Rostedt , Valentin Schneider , Vincent Guittot , Thomas Gleixner Subject: [PATCH] sched/rt: Don't try push tasks if there are none. Message-ID: <20230801152648._y603AS_@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I have a RT task X at a high priority and cyclictest on each CPU with lower priority than X's. If X is active and each CPU wakes their own cylictest thread then it ends in a longer rto_push storm. A random CPU determines via balance_rt() that the CPU on which X is running needs to push tasks. X has the highest priority, cyclictest is next in line so there is nothing that can be done since the task with the higher priority is not touched. tell_cpu_to_push() increments rto_loop_next and schedules rto_push_irq_work_func() on X's CPU. The other CPUs also increment the loop counter and do the same. Once rto_push_irq_work_func() is active it does nothing because it has _no_ pushable tasks on its runqueue. Then checks rto_next_cpu() and decides to queue irq_work on the local CPU because another CPU requested a push by incrementing the counter. I have traces where ~30 CPUs request this ~3 times each before it finally ends. This greatly increases X's runtime while X isn't making much progress. Teach rto_next_cpu() to only return CPUs which also have tasks on their runqueue which can be pushed away. This does not reduce the tell_cpu_to_push() invocations (rto_loop_next counter increments) but reduces the amount of issued rto_push_irq_work_func() if nothing can be done. As the result the overloaded CPU is blocked less often. There are still cases where the "same job" is repeated several times (for instance the current CPU needs to resched but didn't yet because the irq-work is repeated a few times and so the old task remains on the CPU) but the majority of request end in tell_cpu_to_push() before an IPI is issued. Signed-off-by: Sebastian Andrzej Siewior --- kernel/sched/rt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 00e0e50741153..338cd150973ff 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -2247,8 +2247,11 @@ static int rto_next_cpu(struct root_domain *rd) rd->rto_cpu = cpu; - if (cpu < nr_cpu_ids) + if (cpu < nr_cpu_ids) { + if (!has_pushable_tasks(cpu_rq(cpu))) + continue; return cpu; + } rd->rto_cpu = -1; -- 2.40.1