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 9F0EBC4321E for ; Fri, 25 Nov 2022 09:13:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229764AbiKYJNI (ORCPT ); Fri, 25 Nov 2022 04:13:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229682AbiKYJNE (ORCPT ); Fri, 25 Nov 2022 04:13:04 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CA3663AA for ; Fri, 25 Nov 2022 01:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=uAfGoK08v60ApQLBAJVzswYfYs4HD0yYTDh0683H4fc=; b=PGk/pprKsrCCePWlyccHY69C04 jO9m8NtmaTvplw+0ZsANv/OQcz91L0dEnul+FGZNbweMou5G7USM2ZCzjEb650fBk6L3YrqFqwL0/ CQLRzzIy/qZUZbb459WYgVio7LkS92OxHAlrbJbAhCmmi40yXrfCN0rq8LaNDDjj3VEPAB8uudKK5 otYDHw/EPnE6/8J1jONx95PNXJ2WPdWJCLVDOc65mnfnH6qxmWfxBzukDGNTtGdn7f9WU7cz+yBGN 02TbkePMQYWGpruF8x9XKW6zNBx9XpPgrkNoJ4yS7TJQ9M5x3rfmT3eeCsEFv1IInHPeHHEEcEUqC v3SvPEfA==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oyUlV-009SZI-4Y; Fri, 25 Nov 2022 09:12:57 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 2BAF6300282; Fri, 25 Nov 2022 10:12:49 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id ED5E2205E4E96; Fri, 25 Nov 2022 10:12:48 +0100 (CET) Date: Fri, 25 Nov 2022 10:12:48 +0100 From: Peter Zijlstra To: Josh Don Cc: Chengming Zhou , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel@vger.kernel.org, Tejun Heo , Michal =?iso-8859-1?Q?Koutn=FD?= , Christian Brauner , Zefan Li , Thomas Gleixner , Frederic Weisbecker , anna-maria@linutronix.de Subject: Re: [PATCH v3] sched: async unthrottling for cfs bandwidth Message-ID: References: <20221117005418.3499691-1-joshdon@google.com> <094299a3-f039-04c1-d749-2bea0bc14246@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 25, 2022 at 09:59:23AM +0100, Peter Zijlstra wrote: > On Fri, Nov 25, 2022 at 09:57:09AM +0100, Peter Zijlstra wrote: > > On Tue, Nov 22, 2022 at 11:35:48AM +0100, Peter Zijlstra wrote: > > > On Mon, Nov 21, 2022 at 11:37:14AM -0800, Josh Don wrote: > > > > Yep, this tradeoff feels "best", but there are some edge cases where > > > > this could potentially disrupt fairness. For example, if we have > > > > non-trivial W, a lot of cpus to iterate through for dispatching remote > > > > unthrottle, and quota is small. Doesn't help that the timer is pinned > > > > so that this will continually hit the same cpu. > > > > > > We could -- if we wanted to -- manually rotate the timer around the > > > relevant CPUs. Doing that sanely would require a bit of hrtimer surgery > > > though I'm afraid. > > > > Here; something like so should enable us to cycle the bandwidth timer. > > Just need to figure out a way to find another CPU or something. > > Some more preparation... And then I think something like so.. That migrates the timer to the CPU of the first throttled entry -- possibly not the best heuristic, but its the simplest. NOTE: none of this has seen a compiler up close. --- --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5595,13 +5595,21 @@ static bool distribute_cfs_runtime(struc */ static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun, unsigned long flags) { - int throttled; + struct cfs_rq *first_cfs_rq; + int throttled = 0; + int cpu; /* no need to continue the timer with no bandwidth constraint */ if (cfs_b->quota == RUNTIME_INF) goto out_deactivate; - throttled = !list_empty(&cfs_b->throttled_cfs_rq); + first_cfs_rq = list_first_entry_or_null(&cfs_b->throttled_cfs_rq, + struct cfs_rq, throttled_list); + if (first_cfs_rq) { + throttled = 1; + cpu = cpu_of(rq_of(first_cfs_rq)); + } + cfs_b->nr_periods += overrun; /* Refill extra burst quota even if cfs_b->idle */ @@ -5641,7 +5649,7 @@ static int do_sched_cfs_period_timer(str */ cfs_b->idle = 0; - return HRTIMER_RESTART; + return HRTIMER_RESTART_MIGRATE + cpu; out_deactivate: return HRTIMER_NORESTART;