Received: by 10.223.185.116 with SMTP id b49csp1662536wrg; Thu, 22 Feb 2018 00:39:20 -0800 (PST) X-Google-Smtp-Source: AH8x224lqirtG5c2cIgLqDP1IuIubwCjOfu+x6J3J8rzVJ7yAmg/bzVGamtOy1VunUw8tt2WaFXx X-Received: by 2002:a17:902:6b02:: with SMTP id o2-v6mr877932plk.334.1519288760493; Thu, 22 Feb 2018 00:39:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519288760; cv=none; d=google.com; s=arc-20160816; b=nvn8mWGJb0PxZoj+vcI+Urk+Uglfsqq9RWBINmjpxEHPu/cWB+AK3aO1nWAVQcUepy qteP1xof7rSxCS3s01wmOLaTqW72B/trblivFHJN3EseWv4zqal8mzAWyb2tendN3eaa yIuDCHw8TZw0eLXA+eiciGgAUWl0ohZbbXZTMaNbUAMWwQcjYROfepb5dLFatczX5kjT RpAoIGflgf0fs4CK+q4zBCss33tMr6D2SBH9YukoGFzQEYFpaKMJ75lBg7HnGITUSA7E pPX+lVfc2VleyQeHQAIfReIE/R4/YQ3skuOPy+zxsay+ISB3GtvYQZhjlhRAcdxn8G4v ptVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ZU7e9mLS4zmNi4a7ZsWCknnzYrPfdA+eV6ddI/S6uKI=; b=Wy/zHvllCUyQATELy8E+a5SCQdFqIsa2IlIPU+wrEjJSpLycP/C/aBuEcniL2GHHIb 1lUs/ns9UuDmbynHIWcDfh7YG6hY52ebLqN7wtLrS9a/ANqsMF2akBj9Ksxnitm3w9v0 FanXJ++bmu8ZmXCM6/K0ile2aO/R5tGI8OqUtvUyNQ+cLZPFN/W9Uq3wQ/CYyozmTWX0 +OleGnTzQlrXy4Qz7JErwsof9BWx20hCQ0gc8GalBgJ2rtyIdQKsTACRFwXBJK3U3FnB bh6TTvcTtPqNLOL4rajYy3r9eZlwFkGMcap19Xqo5DS+iwBhckHH23WhmdZk8mp9VLVk 3ORQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=j6VINmJX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 206si2373480pgb.647.2018.02.22.00.39.06; Thu, 22 Feb 2018 00:39:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=j6VINmJX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752922AbeBVIh5 (ORCPT + 99 others); Thu, 22 Feb 2018 03:37:57 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:33770 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752826AbeBVIh4 (ORCPT ); Thu, 22 Feb 2018 03:37:56 -0500 Received: by mail-it0-f67.google.com with SMTP id q4so1057747itc.0 for ; Thu, 22 Feb 2018 00:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZU7e9mLS4zmNi4a7ZsWCknnzYrPfdA+eV6ddI/S6uKI=; b=j6VINmJXYUWk6WnybLqPPC7iKckQQCpJbFPlkVuCcD3c9ql47tXktY3QvnMFPbDc4R 9qSGDRDPF7hYelAMDWFmBc3MHpr+PRdmFEyNtai0g3pISO59uwfJCkL0+M5dhT87BoF2 H6jpiyucP7aaNTEmzeUdzCV6Ua8BmealtA/OE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZU7e9mLS4zmNi4a7ZsWCknnzYrPfdA+eV6ddI/S6uKI=; b=M3nE6Rle5ioPK/F5V8gBn3wGnDNTSlZRr23XOsSnuFj4GCLDVvqoqxVbWjoP8xVYUj F65NeJDwdM9JwD4aV9KWiPtc6MQqAPaNwPN0tT+LYDGt1PGe2J2cgIw/fWKTY0xVDfT/ YdIMYpnRxoENZfV0fq/lcKLPuWonocl80jLL2vtFtzgh8ltnda4uM7X9f9pHurzo7b28 tOWHWemCTyMAxB6c8hJvna6iHIcV68Nvp5IAiOL/E5yj3XNpAlhbJ1O3xHpUwtgl07kP JgS0pSR4rq/uPCi8iaBb1n5ZNVVhQZONbTNX3b9cdY1HDywgsoyokFEWgIFOVFCiN/ZF G3Hw== X-Gm-Message-State: APf1xPC3BXJcdPY685VR45SEF+27n6laYUT5EtWy0eAdnY5oUAtK4Qg/ aF+KKNK2CsnlzqDMMiF8ve8wp7+KbHzyzSmzLODWQw== X-Received: by 10.36.207.70 with SMTP id y67mr7026561itf.148.1519288675087; Thu, 22 Feb 2018 00:37:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.83 with HTTP; Thu, 22 Feb 2018 00:37:34 -0800 (PST) In-Reply-To: References: <1518622006-16089-1-git-send-email-vincent.guittot@linaro.org> <1518622006-16089-2-git-send-email-vincent.guittot@linaro.org> <44a7d9dc-f6f3-e003-44d6-b0c4aa7dc046@arm.com> From: Vincent Guittot Date: Thu, 22 Feb 2018 09:37:34 +0100 Message-ID: Subject: Re: [PATCH v5 1/3] sched: Stop nohz stats when decayed To: Valentin Schneider Cc: Peter Zijlstra , Ingo Molnar , linux-kernel , Morten Rasmussen , Brendan Jackman , Dietmar Eggemann Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21 February 2018 at 14:13, Valentin Schneider wrote: > On 02/16/2018 01:44 PM, Vincent Guittot wrote: >> On 16 February 2018 at 13:13, Valentin Schneider >> wrote: >>> On 02/14/2018 03:26 PM, Vincent Guittot wrote: >>>> Stopped the periodic update of blocked load when all idle CPUs have fully >>>> decayed. We introduce a new nohz.has_blocked that reflect if some idle >>>> CPUs has blocked load that have to be periodiccally updated. nohz.has_blocked >>>> is set everytime that a Idle CPU can have blocked load and it is then clear >>>> when no more blocked load has been detected during an update. We don't need >>>> atomic operation but only to make cure of the right ordering when updating >>>> nohz.idle_cpus_mask and nohz.has_blocked. >>>> >>>> Suggested-by: Peter Zijlstra (Intel) >>>> Signed-off-by: Vincent Guittot >>>> --- >>>> kernel/sched/fair.c | 122 ++++++++++++++++++++++++++++++++++++++++++--------- >>>> kernel/sched/sched.h | 1 + >>>> 2 files changed, 102 insertions(+), 21 deletions(-) >>>> >>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>>> index 7af1fa9..5a6835e 100644 >>>> --- a/kernel/sched/fair.c >>>> +++ b/kernel/sched/fair.c >>>> >>>> [...] >>>> @@ -9383,11 +9452,16 @@ static bool nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle) >>>> * work being done for other cpus. Next load >>>> * balancing owner will pick it up. >>>> */ >>>> - if (need_resched()) >>>> - break; >>>> + if (need_resched()) { >>>> + has_blocked_load = true; >>>> + goto abort; >>>> + } >>>> >>>> rq = cpu_rq(balance_cpu); >>>> >>> >>> I'd say it's safe to do the following here. The flag is raised in >>> nohz_balance_enter_idle() before the smp_mb(), so we won't skip a CPU >>> that just got added to nohz.idle_cpus_mask. >> >> rq->has_blocked_load will be set before the barrier only if >> nohz_tick_stopped is not already set, >> Otherwise, we skip cpumask update and the barrier in nohz_balance_enter_idle >> > > Right, forgot about that bit. I think it's still fine because: > - nohz_balance_enter_idle() can't be called before the last running task is > dequeued, which requires the rq lock. > - update_blocked_averages takes the rq lock and clears rq->has_blocked_load > with the lock held. > > So even though we could have some very unlikely scenario where a CPU quickly > goes out/in of idle after nohz.idle_cpus_mask has been read, the blocked load > itself is safe so rq->has_blocked_load will end up being set correctly. > (Took me a while to see it that way) > > > BTW, with the current set on Peter's sched/testing, update_nohz_stats() > is called here, which doesn't do the update if !rq->has_blocked_load > (Although that check is done without lock/barrier, so maybe we could not see > a CPU that just went idle ?) > > I have one more question on that bit: > > > has_blocked_load |= update_nohz_stats(rq, true); > > /* > * If time for next balance is due, > * do the balance. > */ > if (time_after_eq(jiffies, rq->next_balance)) { > struct rq_flags rf; > > rq_lock_irqsave(rq, &rf); > update_rq_clock(rq); > cpu_load_update_idle(rq); > rq_unlock_irqrestore(rq, &rf); > > if (flags & NOHZ_BALANCE_KICK) > rebalance_domains(rq, CPU_IDLE); > } > > if (time_after(next_balance, rq->next_balance)) { > next_balance = rq->next_balance; > update_next_balance = 1; > } > > > Now that I think about it, shouldn't we always have a 'continue' after > the blocked load update if (flags & NOHZ_KICK_MASK) == NOHZ_STATS_KICK ? > AFAICT we don't want to push the next_balance forward, only the next_blocked. But we don't push next_balance forward. It just get the shortest next_balance and update nohz.next_balance exactly like what is done in full idle load balance > That would also take care of not doing the load balance. >>> >>> /* >>> * This cpu doesn't have any remaining blocked load, skip it. >>> * It's sane to do this because this flag is raised in >>> * nohz_balance_enter_idle() >>> */ >>> if ((flags & NOHZ_KICK_MASK) == NOHZ_STATS_KICK && >>> !rq->has_blocked_load) >>> continue; Then, it's worth keeping the call to cpu_load_update_idle(rq); which update the cpu_load[] array which is still used at some level >>> >>>> + update_blocked_averages(rq->cpu); >>>> + has_blocked_load |= rq->has_blocked_load; >>>> +