Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp2569759rdb; Fri, 22 Sep 2023 02:29:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE6+BBUp3jI/DTCtq5ypy6UlZuwqHeO5Wkj/sJh+iEtjXoXsss/ul/QrK+NvAC0KxeFNaQB X-Received: by 2002:aca:110e:0:b0:3a7:4a89:7510 with SMTP id 14-20020aca110e000000b003a74a897510mr7389128oir.30.1695374965451; Fri, 22 Sep 2023 02:29:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695374965; cv=none; d=google.com; s=arc-20160816; b=Q5MupVQH8fdQCiXXsN/zn9oRFKRwuD/7kyBs0lfr/5XIw0gtVjQXZfWtZVGShUCy+R r2I4G83iuAl7nhCE67UGbI11PHj1cR3QeG82aBjzhuyuankQOoZi3054MEqOpNJ/+uNG l1gjzI8zguKj/PJzQobMX06jdRAFAzf5pGProHyKaf7CjHi42BFZqgGRdAv1aGi+HJB4 M25YfeAh59Q3YlNuR+Yo+Shqsxreeb/bg7OhF41faebyaPJaIWRCUgeLmflT07EpZLA+ c0qscEN7ulRG+N2TbhJPSiSKcvQk4koYrR2Xy+QsISSollRVp+lzcvyu/0oqK98MlvjC zPjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=ImV7moxaH4nIogkks9X+lfrtLjUx4JnnRZu2gqe0D7Y=; fh=5ViOKAlwuIKKuOGmK49gJRYpczJpkf0p0lkA5d8Nb94=; b=tf+ori9ZZTXMSnXLPmtRrNynwS3fSAJ8wDKBmd+628sPJotXRYUuMD+fPGlIv6lktx j8OoKcPJxQlwQFoAsev1US02ir3GiYy/1dU0RktdEowZDBitYOigD3lnsCaqLvEoi8ov Vg6YtMzvHb/ecyFvcJHoUafaDHOPcwV8tGYid1h0Xtw2rkT+PRmVrpXP/4gIvT9MkQ2s vDCmL0k7IqK2n42YkdcPMShaMct5mrsyHNOi2ivZuL5UKLgkHSf2VjGTeQNXlxXh/C5z 1ce1l8XS261nxgSHzEftcK5ak/kmjE3/VGy6Rs1qkUF6oguLuvlcPRqj1OYWx3Z0vq20 l7fQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=CuvOYzf6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id k21-20020aa788d5000000b00690feb23e3esi3594822pff.17.2023.09.22.02.29.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 02:29:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=CuvOYzf6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 48B6D8057B3C; Fri, 22 Sep 2023 01:14:36 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232712AbjIVIOg (ORCPT + 99 others); Fri, 22 Sep 2023 04:14:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232333AbjIVIOP (ORCPT ); Fri, 22 Sep 2023 04:14:15 -0400 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E73012D69 for ; Fri, 22 Sep 2023 01:13:15 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4053c6f0d55so7096155e9.0 for ; Fri, 22 Sep 2023 01:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695370394; x=1695975194; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=ImV7moxaH4nIogkks9X+lfrtLjUx4JnnRZu2gqe0D7Y=; b=CuvOYzf6JBdS+sIJ2wVZWkdjVJLbu0huqQIkOVIB6VlOnRsS2da3+StyuppplwmgMB PZZdb/AtnxcWHgGbvieFoeOcYaoRDskyAn1qZmXklPIF07EVs4BzjqKsrYebWtvHOIL8 JUQ4zE8LjL2xtljmJUWbT497NPjhaDmpWbxaWmm7b9VdlY4+4QEh85n/D/X5LkoNgLWw 1wsqT53U2Bek0CCBSDu2kIb5VLhLneGVw+KEsg/amRr1L59DiYqEFaW+vZFct1d63Lq1 47nQ5AHc1jdifmeFPbt32ReNUCPvdH+RPN5Z4PTSYxcXwo/FAiFAMfB1EpoUWxnZCjz4 iLbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695370394; x=1695975194; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ImV7moxaH4nIogkks9X+lfrtLjUx4JnnRZu2gqe0D7Y=; b=hNSS9jlOmLhvpyVIqRarK5t+m0qz2aE31Bfdl7c0PvIqPwLPP3J1hNmrn4/t3N6dH9 A0Fo2dKiAJ4HfaqflelvoXQhcoYIDiO5e1fucijAsLkauONcDPuXRJwmKpHBfSgqxVBk 8ooZACMuhgbJ6Rbc4dcUzMfdjDfECvQpUEcXrOCCxu6aYA+/BoWmpsW6qQdEjuHtfUE7 wf/yjo9ci3WPXA+xjB593fhb8d/8cNWxc/Turs9SU6BUBJGzPnmN1NwiLwnVy3Ff/t54 rUA9O/SBX/q15e3ywC/7q9xMbmBpebr17DoEDfkggw8OtIrNVcKq0NYimAtIEM1+TRUT hSOQ== X-Gm-Message-State: AOJu0Yzs8FAyJFr+xxCQxw0/P3cb3yuEA0PZbypo5asc1VhH588e41Br VtHDI1hhpxm2dTJ/cJCjZus= X-Received: by 2002:a1c:4b12:0:b0:3fe:1f93:8cf4 with SMTP id y18-20020a1c4b12000000b003fe1f938cf4mr7545608wma.8.1695370394101; Fri, 22 Sep 2023 01:13:14 -0700 (PDT) Received: from gmail.com (1F2EF49C.nat.pool.telekom.hu. [31.46.244.156]) by smtp.gmail.com with ESMTPSA id c23-20020a7bc857000000b003fefca26c72sm3981686wml.23.2023.09.22.01.13.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 01:13:13 -0700 (PDT) Sender: Ingo Molnar Date: Fri, 22 Sep 2023 10:13:11 +0200 From: Ingo Molnar To: Josh Don Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched: fix warning in bandwidth distribution Message-ID: References: <20230922013750.874131-1-joshdon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230922013750.874131-1-joshdon@google.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 22 Sep 2023 01:14:36 -0700 (PDT) * Josh Don wrote: > We've observed the following warning being hit in > distribute_cfs_runtime(): > SCHED_WARN_ON(cfs_rq->runtime_remaining > 0) > > We have the following race: > > - cpu0: running bandwidth distribution (distribute_cfs_runtime). > Inspects the local cfs_rq and makes its runtime_remaining positive. > However, we defer unthrottling the local cfs_rq until after > considering all remote cfs_rq's. > - cpu1: starts running bandwidth distribution from the slack timer. When > it finds the cfs_rq for cpu 0 on the throttled list, it observers the > that the cfs_rq is throttled, yet is not on the CSD list, and has a > positive runtime_remaining, thus triggering the warning in > distribute_cfs_runtime. > > To fix this, we can rework the local unthrottling logic to put the local > cfs_rq on a local list, so that any future bandwidth distributions will > realize that the cfs_rq is about to be unthrottled. > > Signed-off-by: Josh Don > --- > v2: Fix build error on !CONFIG_SMP > > kernel/sched/fair.c | 43 +++++++++++++++++++++++++++++++++---------- > 1 file changed, 33 insertions(+), 10 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 384900bf87eb..3d1886ea18fe 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -5743,13 +5743,16 @@ static void unthrottle_cfs_rq_async(struct cfs_rq *cfs_rq) > > static bool distribute_cfs_runtime(struct cfs_bandwidth *cfs_b) > { > - struct cfs_rq *local_unthrottle = NULL; > int this_cpu = smp_processor_id(); > u64 runtime, remaining = 1; > bool throttled = false; > struct cfs_rq *cfs_rq; > struct rq_flags rf; > struct rq *rq; > +#ifdef CONFIG_SMP > + struct cfs_rq *tmp; > + LIST_HEAD(local_unthrottle); > +#endif > > rcu_read_lock(); > list_for_each_entry_rcu(cfs_rq, &cfs_b->throttled_cfs_rq, > @@ -5786,11 +5789,21 @@ static bool distribute_cfs_runtime(struct cfs_bandwidth *cfs_b) > > /* we check whether we're throttled above */ > if (cfs_rq->runtime_remaining > 0) { > - if (cpu_of(rq) != this_cpu || > - SCHED_WARN_ON(local_unthrottle)) > +#ifdef CONFIG_SMP > + if (cpu_of(rq) != this_cpu) { > unthrottle_cfs_rq_async(cfs_rq); > - else > - local_unthrottle = cfs_rq; > + } else { > + /* > + * We currently only expect to be unthrottling > + * a single cfs_rq locally. > + */ > + SCHED_WARN_ON(!list_empty(&local_unthrottle)); > + list_add_tail(&cfs_rq->throttled_csd_list, > + &local_unthrottle); > + } > +#else > + unthrottle_cfs_rq_async(cfs_rq); > +#endif > } else { > throttled = true; > } > @@ -5798,15 +5811,25 @@ static bool distribute_cfs_runtime(struct cfs_bandwidth *cfs_b) > next: > rq_unlock_irqrestore(rq, &rf); > } > - rcu_read_unlock(); > > - if (local_unthrottle) { > - rq = cpu_rq(this_cpu); > +#ifdef CONFIG_SMP > + list_for_each_entry_safe(cfs_rq, tmp, &local_unthrottle, > + throttled_csd_list) { > + struct rq *rq = rq_of(cfs_rq); > + > rq_lock_irqsave(rq, &rf); > - if (cfs_rq_throttled(local_unthrottle)) > - unthrottle_cfs_rq(local_unthrottle); > + > + list_del_init(&cfs_rq->throttled_csd_list); > + > + if (cfs_rq_throttled(cfs_rq)) > + unthrottle_cfs_rq(cfs_rq); > + > rq_unlock_irqrestore(rq, &rf); > } > + SCHED_WARN_ON(!list_empty(&local_unthrottle)); > +#endif So instead of uglifying the code with seldom-tested !CONFIG_SMP #ifdefs, please fold the !SMP code into SMP code: make ->throttled_csd_list unconditional in a preparatory patch (even if it's essentially unused on !SMP), then add what is basically your v1 patch as a second patch in the series to fix the bug. We want to unify as much of the SMP and !SMP codepaths as possible, even when it casuses a bit of runtime overhead for !SMP. Thanks, Ingo