Received: by 10.223.185.116 with SMTP id b49csp1041709wrg; Fri, 16 Feb 2018 11:19:47 -0800 (PST) X-Google-Smtp-Source: AH8x2277POhtxMdhb6NZbBud6wUf0J5ztUJVwFglvuV9xqL2V0XHhnFhp+KM6NfthNjiUtbVF2OK X-Received: by 10.99.116.25 with SMTP id p25mr6005273pgc.109.1518808786942; Fri, 16 Feb 2018 11:19:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518808786; cv=none; d=google.com; s=arc-20160816; b=c2p/rUhWTr5X0o5Zmb7OfTusGc8XyFmR8KVjdAA4G6FEfMQkSba6zS2I259W6gdaY7 MPx236MG+WndIC/5WGR3oxEi+sSJET+MOY7Wj5ueFSj4zkWHeD2TrPhYQE8eia6AG0FG 5fIhpiSKyiKfTH4cs3ou46KOloxEm8C0PbCvrzFKZh6od2RackBrJTJBNNkIXKpwLgcV jDk7iLKoHCG33obvi0oSE2B5RD73aPu33SMtbThcFhAyuXLt03PwT/VpxxxuRCqBTv8O +kLDFaWBqJxz0YpYC1Ij8RJdRmb3fvDmms9pVLO7esjORI84RA6So0fwF2L95Q0nfPIx Q4Qw== 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=yTsGYMaBSlX2UCUoE2N4X7sP7YUawvHnI8Sre3tDYcU=; b=ouylAPD5psO1xBIWkVa8hbSgKxs8Qvi3g/2JBd8x8gQmNzhisptQr12ZKSx15TzuAi IoTFCSN+Zs2le4KrPjpwO9V0+qubCV8CCzj/rs0cX/92W18qexvgJhhz5y81mCHDVsbz rWuVfmuyaO/fnInTfZrEEyRo3OBqiXw/mVXdJ1+hXHPL8kcvo+ZH1gIHrqbXKKB0byNm uzzu1gUwBl41b+jLsNd7NwoA6PsXjA7bnDG+s7/V7KQNQMMm0CAHAuw+WLzYybF0/l8F S0nerGUF1V8EU9CtdvBoBpU6ZisIhoFx4sxAjRKUyB1hlF6AxdN1+TbKfetJ2suvvkIZ YKlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=RxKAsAhU; 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 64-v6si1686601plk.167.2018.02.16.11.19.32; Fri, 16 Feb 2018 11:19:46 -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=RxKAsAhU; 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 S1758782AbeBPRDW (ORCPT + 99 others); Fri, 16 Feb 2018 12:03:22 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:50978 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755857AbeBPRDV (ORCPT ); Fri, 16 Feb 2018 12:03:21 -0500 Received: by mail-it0-f65.google.com with SMTP id y16so2540770itc.0 for ; Fri, 16 Feb 2018 09:03:20 -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=yTsGYMaBSlX2UCUoE2N4X7sP7YUawvHnI8Sre3tDYcU=; b=RxKAsAhU6WHe4GgNrahnLo8It6Z9chRhqYotesNZYaswqGMDEebwMS3iF+Q6RMEEqY cvWWZLyzRtZCfH1vhf+C6ERnLziciMDkF5oF1gALn3Fg4aKZ21BzIMQtax5QUk8ZHWHW St1LlmMdeLeyEl86mmpyNnbjdz8W+Dq8l9RKI= 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=yTsGYMaBSlX2UCUoE2N4X7sP7YUawvHnI8Sre3tDYcU=; b=cuyhrqPlJOUACdNQl6zrUCvwfR4DhFKsGDSugrtXppxt4cMvfpSEADjniWT5JRgrKP ZAcO04L1U+5efbTkj4lZYgwoiBtd5m7oirGLLKjM36oo2dgmlzDThKKixxYPNH5Qj/bk GI1eWqJU6ArDm/5ePHbcv1OL5jGDbVvY/SJIzkRD1rQ7EYVumYMlQts394n/ftfDBtAT VH5yed1rD7FHL+/jVSZao5Q+MDsfvHX+Xt+UTlCWzbQGAdoR90/hljmYWTK7YHjx4utu wC7TUmwKHkdge1Ycuw3fBVNkzaVrIpIhI6o/+2MGctvxeEGJZg6nq6pDMo45VvX23I+o vHLg== X-Gm-Message-State: APf1xPCEI8S1UycAMtzY2IEvoK75bwfH2O/ANb5agMTPAEmE/gNE2ZCM wTe4wtIop9Lj6Fc3wNjk21UiEIayCNp+ud3XcDHCETbhb+Y= X-Received: by 10.36.249.129 with SMTP id l123mr9330417ith.30.1518800600112; Fri, 16 Feb 2018 09:03:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.83 with HTTP; Fri, 16 Feb 2018 09:02:59 -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> From: Vincent Guittot Date: Fri, 16 Feb 2018 18:02:59 +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 16 February 2018 at 13:53, 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 >> >> [...] >> >> -static void update_nohz_stats(struct rq *rq) >> +static bool update_nohz_stats(struct rq *rq) >> { >> #ifdef CONFIG_NO_HZ_COMMON >> unsigned int cpu = rq->cpu; >> >> + if (!rq->has_blocked_load) >> + return false; >> + >> if (!cpumask_test_cpu(cpu, nohz.idle_cpus_mask)) >> - return; >> + return false; >> >> if (!time_after(jiffies, rq->last_blocked_load_update_tick)) >> - return; >> + return true; >> >> update_blocked_averages(cpu); >> + >> + return rq->has_blocked_load; >> +#else >> + return false; >> #endif >> } >> > > (Wrongly thought that this bit was in a different patch, comment should have > been squashed in previous reply...) > > I've been thinking about this, and it's a messy one if we want to > skip CPUs in idle_balance() / clear the nohz.has_blocked_flag. > > AFAICT, the rq->has_blocked_load flag can be wrongly cleared: if we're > calling update_nohz_stats() for CPU A, but CPU A got out/in of > idle really quickly in that same timeframe, I'm not sure you can guarantee > the clearing of rq->has_blocked_load done in update_blocked_averages() will > always end up in memory before the setting of the flag in > nohz_balance_enter_idle(). Not sure it's a problem in this case because the clear done in update_blocked_averages() only happens if there is no load on the rq and new load can't be added in the mean time > > I was going to say we don't have this problem in _nohz_idle_balance() but > actually I think we do. We have the checking of nohz.idle_cpus_mask after the > smp_mb(), which makes sure the clear of nohz.has_blocked will never > overwrite the set in nohz_balance_enter_idle(), but it doesn't > guarantee the same for the rq flag. So we can have nohz CPUs with blocked > load but with rq->has_blocked_load set to false. Which isn't a problem now I don't think that we can have this case. Or at least I can't find a sequence leading to this state. Have you got a particular sequence in mind ? > but it is if we want to use the flag to skip CPUs. > > Am I correct or am I going crazy ? There's a comment about this in > nohz_balance_enter_idle() but I'm confused now: > > /* > * Can be set safely without rq->lock held > * If a clear happens, it will have evaluated last additions because > * rq->lock is held during the check and the clear > */ > rq->has_blocked_load = 1;