Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2484512pxb; Mon, 19 Apr 2021 06:52:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzb42fsiHaR+tQV0ARJEG8pLw/et3yygBLs1WX2LegbTC2ABQLo2zNO5J2DeKb3vY2tOSpS X-Received: by 2002:a17:90a:6407:: with SMTP id g7mr24203922pjj.206.1618840355614; Mon, 19 Apr 2021 06:52:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618840355; cv=none; d=google.com; s=arc-20160816; b=lphmoDzOSia3tWlnhcH5PN7ca6p20VVJ0doZvU44vopig2YicLsgTt5qx1f1hf+QRd fO1vKyQgyLTe1lTx1eiQ5hurj+thCVq7hAiqN0AD9XoZrXkzoTNgbEVQ4w5qnA1ALkGd QbD1DhqH87h0FIylx/Drh5zIQkixXzutj3TzPQnLBIERFaE6dl3E7yAujbcx6mVLDNJm LekdlX6BJXyu3Yzk+/oa+EchVRPHNmajPrzXFrCre9Aq6Jx21OguibFcGA3zKgpZoSQd mlzeJ17PYxt22BolEO6rHyFF5K9cZ+Zby0ZcKKFV4DsfxeXlQNiRD7EGCNxTjhoBQMDp yvkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=lFkFHMrjz2XuV/8N+BC5I1mmN+OFVgENp6a9G/NdgNs=; b=HwKErk1w73c2hTy8jMcd27QN4kbM2UwIzz3sbJepEy6C1VrjdgNuO/pkXzc3wFAx9i xIv+DC2jRlNfO2Ymb6XG9Iidz/34JZLpcDtOEHRmGkzBGovssU/YYoID7iOslN18QLar X3bHv+awHQw13E7tW7ZmE1ofdgmmONrsMRkuCxM8d4JnNddHlVtFEjPJkqXVi7L+1JIS wdjWkTUUX7bbNgE0pMOjdfknD/f9f6mK00qgl2LEikCnzfJjc2pMf3G6SS8zJSF8Zr79 DWujNptd3/Ci9F7RoXZJt5lPr3Qn1Gikkb4iEy8MJ9KGQ/3uzcBvPDbbcgn95hfra29O kCGQ== 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 5si7278138pli.426.2021.04.19.06.52.23; Mon, 19 Apr 2021 06:52:35 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237765AbhDSLWn (ORCPT + 99 others); Mon, 19 Apr 2021 07:22:43 -0400 Received: from foss.arm.com ([217.140.110.172]:40836 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235872AbhDSLWm (ORCPT ); Mon, 19 Apr 2021 07:22:42 -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 F07D631B; Mon, 19 Apr 2021 04:22:12 -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 D2F043F792; Mon, 19 Apr 2021 04:22:11 -0700 (PDT) From: Valentin Schneider To: Rik van Riel , linux-kernel@vger.kernel.org Cc: kernel-team@fb.com, Peter Zijlstra , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Mel Gorman Subject: Re: [PATCH] sched,fair: skip newidle_balance if a wakeup is pending In-Reply-To: <20210418221751.7edfc03b@imladris.surriel.com> References: <20210418221751.7edfc03b@imladris.surriel.com> Date: Mon, 19 Apr 2021 12:22:06 +0100 Message-ID: <87lf9eldsx.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/04/21 22:17, Rik van Riel wrote: > @@ -10661,7 +10669,8 @@ static int newidle_balance(struct rq *this_rq, struct rq_flags *rf) > * Stop searching for tasks to pull if there are > * now runnable tasks on this rq. > */ > - if (pulled_task || this_rq->nr_running > 0) > + if (pulled_task || this_rq->nr_running > 0 || > + this_rq->ttwu_pending) > break; I thought newidle_balance() would already handle this by checking idle_cpu(), but that can't work due to rq->curr never being rq->idle here (we're trying very hard to prevent this!). Would there be any point in bunching up these two checks from idle_cpu() into an inline helper and reusing it here? _nohz_idle_balance() "accidentally" already checks for that, but at the head of the domain loop. What's the reason for doing it at the tail here? It means we try at least one loop, but is there a point in that? > } > rcu_read_unlock(); > -- > 2.25.4