Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1689130ybj; Wed, 6 May 2020 03:30:53 -0700 (PDT) X-Google-Smtp-Source: APiQypJc+XM2eDH94Zow+ZVgO0fWq5GLi7E7Fj+ESrGCTGIFZd6NTIdaVWnzf3DhSKrJN2knAv32 X-Received: by 2002:a17:906:d10b:: with SMTP id b11mr6448797ejz.62.1588761053111; Wed, 06 May 2020 03:30:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588761053; cv=none; d=google.com; s=arc-20160816; b=w5zdp/v0tr1rcyzIBPchEi6cUheb3hfpWf6snEBxG7i3nOEB+WCThWoh4KE6cFB7ib hgV0DjVv4sR3q6jHx/P28Ah2lZjC2rVzObH+sfiF5CnqFqsME2+pN8tyn0wBTtyn0Pdo 8ulTQJ7lK+xXG6PYmJfeEBzNK48G6lqs9VKROqXXyY/YglsQve92fzdFH40UV2+C/FWm YD8/VZtSLflgq9atqg22JWrElXkty2wQvti2XKOboDDuAuBUH13cbX7DIXBNI2iDQqMW uoPWXtiaROvBo34b4D/jGwYDIf7AmmnAPqLcO+6sWRHak3eqsMenniQhO7O+LF2S9uTD 1rXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=+tD8L7Yeb8Oscyf7M1xedpf1/noTC3ta26rfGb8TFl0=; b=DuiToSsA44KvENi7ZV9b/igwNSaJyYaRoie4QEFFE0OACSFw9zDb0UiqTqGFIniPxY yKRzHbKvHnrn3L+nzh5hTRscz5zgTJhfr7RRVprAdr5YSc/vkwEDeMrDkjB9ESI08EI7 82YZB+lZ1VJeCpMOHnAjWtTBM0uxtL8erx8oY4B6y2sZhfZOVe57ewxlGEfC4Jgxalim M2aIaMtRTbHUWeQM1ZuCD6BiP97EzZaT/AxFLUSOWQneUG2D1OeP9iJXxTXlb4AbCvaj iJ87d8CAPrgw3BJdXu6fCAt35ACccCzLJ8Gh3NOKcDAd37QcgQ6j2Q7yu4bg++eXywyZ 0Cow== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si775320edr.46.2020.05.06.03.30.29; Wed, 06 May 2020 03:30:53 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729105AbgEFK2i (ORCPT + 99 others); Wed, 6 May 2020 06:28:38 -0400 Received: from foss.arm.com ([217.140.110.172]:33244 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728338AbgEFK2i (ORCPT ); Wed, 6 May 2020 06:28:38 -0400 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 BBCA530E; Wed, 6 May 2020 03:28:35 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6B01B3F71F; Wed, 6 May 2020 03:28:34 -0700 (PDT) References: <20200503083407.GA27766@iZj6chx1xj0e0buvshuecpZ> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Vincent Guittot Cc: Peng Liu , linux-kernel , Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman Subject: Re: [PATCH] sched/fair: Fix nohz.next_balance update In-reply-to: Date: Wed, 06 May 2020 11:28:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/05/20 16:17, Vincent Guittot wrote: >> Since we can gather all the updated rq->next_balance, including this_cpu, >> in _nohz_idle_balance(), it's safe to remove the extra lines in >> rebalance_domains() which are originally intended for this_cpu. And >> finally the updating only happen in _nohz_idle_balance(). > > I'm not sure that's always true. Nothing prevents nohz_idle_balance() > to return false . Then run_rebalance_domains() calls > rebalance_domains(this_rq ,SCHED_IDLE) outside _nohz_idle_balance(). > In this case we must keep the code in rebalance_domains(). > > For example when the tick is not stopped when entering idle. Or when > need_resched() returns true. > Going back to this; nohz_idle_balance() will return true regardless of the return value of _nohz_idle_balance(), so AFAICT we won't fall through to the rebalance_domains() in run_rebalance_domains() in case we had need_resched() in _nohz_idle_balance(). This was changed in b7031a02ec75 ("sched/fair: Add NOHZ_STATS_KICK"); before then we would always have the local rebalance_domains(). Now, since the bail out is caused by need_resched(), I think it's not such a crazy thing *not* to do the local rebalance_domains(), but I wasn't super clear on all of this.