Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1290445pxb; Fri, 22 Jan 2021 11:39:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJxdof3tl/h9jh97maaWVTxlqbFIWVBIMcyxfhKhsZalrQEFplCCmVo28rXqSYQKDDixkeQ+ X-Received: by 2002:a17:907:a06f:: with SMTP id ia15mr4032370ejc.328.1611344364616; Fri, 22 Jan 2021 11:39:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611344364; cv=none; d=google.com; s=arc-20160816; b=fWduAQO4nskmoxh8GlBRKnb6FnJWwo5C1jfb7eBLFffgZqI82/to0iH66GP22hh1Cc Pbu/x4MFkhNP+D1zE0c0FWf7ktQ6lFNj4fdUx4Lp2bG1K3tL8LgsZGM+kEdBqSJPKGlf 8WnsOwGOIoa0sY4InK937tDBs//9zGQ4UJTAZCtoBJZcjNUZDm+AoaDBHqnDSEwT8Q7p wk5iNOqCGoDL/nFRzAILduPpPntz1fVDAkNob3iSozpxVXv8iAIsnjCXIgJtZKT12J7J WMwSDJV4i0wCkA8K3fBhmX0u/40xbfkiCYe9Eg6kJHDu16+qKMCq3MoUBvYDU8XxWHsp 6GPA== 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; bh=iH9CtpZBZFEOzAn9zn5oXyEefF/UUMPItwXqL34yJFg=; b=kVd6n70k/gaSM/VpoE1wIvs3cmaUQsl9YwZpcUfIHR7grUPQS6MidWsDTNkCF9eLDV Jjo58Dyou7q4ArZ7HOx0vaP1O3CBXgx9utj14uAavNB8DgsznXCO7UUg/B9Aa2MCDyeV QFFi7vwsJqh/ESRGVSo4D6ssmsos+4gQ8PlvniZIQ11aXnHF3ZYyS+jxSrIN5DfgQeNf saT1gHocJnXIFiLkADvBwLBc+KXLQ33+vyfjepFk5wfAqZ+HeILe+L/bzOP0YBjQTCOF xZAj1cXW+gx7YUB/KKn+OHzlpf/MzDzHgnRKE5tq5DowbnCDWUj8T0F8x+8EbEeXLgTg ZGpA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g1si3382373ejc.697.2021.01.22.11.39.00; Fri, 22 Jan 2021 11:39:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730612AbhAVT0T (ORCPT + 99 others); Fri, 22 Jan 2021 14:26:19 -0500 Received: from foss.arm.com ([217.140.110.172]:32964 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729651AbhAVSkY (ORCPT ); Fri, 22 Jan 2021 13:40:24 -0500 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 3FA48139F; Fri, 22 Jan 2021 10:39:31 -0800 (PST) Received: from e107158-lin (e107158-lin.cambridge.arm.com [10.1.194.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 943993F719; Fri, 22 Jan 2021 10:39:29 -0800 (PST) Date: Fri, 22 Jan 2021 18:39:27 +0000 From: Qais Yousef To: Vincent Guittot Cc: "Joel Fernandes (Google)" , linux-kernel , Paul McKenney , Frederic Weisbecker , Dietmar Eggeman , Ben Segall , Daniel Bristot de Oliveira , Ingo Molnar , Juri Lelli , Mel Gorman , Peter Zijlstra , Steven Rostedt Subject: Re: [PATCH] sched/fair: Rate limit calls to update_blocked_averages() for NOHZ Message-ID: <20210122183927.ivqyapttzd6lflwk@e107158-lin> References: <20210122154600.1722680-1-joel@joelfernandes.org> 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 01/22/21 17:56, Vincent Guittot wrote: > > --- > > kernel/sched/fair.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 04a3ce20da67..fe2dc0024db5 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -8381,7 +8381,7 @@ static bool update_nohz_stats(struct rq *rq, bool force) > > if (!cpumask_test_cpu(cpu, nohz.idle_cpus_mask)) > > return false; > > > > - if (!force && !time_after(jiffies, rq->last_blocked_load_update_tick)) > > + if (!force && !time_after(jiffies, rq->last_blocked_load_update_tick + (HZ/20))) > > This condition is there to make sure to update blocked load at most > once a tick in order to filter newly idle case otherwise the rate > limit is already done by load balance interval > This hard coded (HZ/20) looks really like an ugly hack This was meant as an RFC patch to discuss the problem really. Joel is seeing update_blocked_averages() taking ~100us. Half of it seems in processing __update_blocked_fair() and the other half in sugov_update_shared(). So roughly 50us each. Note that each function is calling an iterator in return. Correct me if my numbers are wrong Joel. Running on a little core on low frequency these numbers don't look too odd. So I'm not seeing how we can speed these functions up. But since update_sg_lb_stats() will end up with multiple calls to update_blocked_averages() in one go, this latency adds up quickly. One noticeable factor in Joel's system is the presence of a lot of cgroups. Which is essentially what makes __update_blocked_fair() expensive, and it seems to always return something has decayed so we end up with a call to sugov_update_shared() in every call. I think we should limit the expensive call to update_blocked_averages() but I honestly don't know what would be the right way to do it :-/ Or maybe there's another better alternative too.. Thanks -- Qais Yousef > > > return true; > > > > update_blocked_averages(cpu); > > -- > > 2.30.0.280.ga3ce27912f-goog > >