Received: by 10.223.176.5 with SMTP id f5csp2977541wra; Thu, 1 Feb 2018 08:54:16 -0800 (PST) X-Google-Smtp-Source: AH8x224hMAw9CFNc6eALJ3FzN5VwZKVjoZ5MduAxLw3VRVmuUL0dVBolOnP2dhfatYiFNgVhHIMd X-Received: by 10.101.88.138 with SMTP id d10mr30399113pgu.52.1517504056553; Thu, 01 Feb 2018 08:54:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517504056; cv=none; d=google.com; s=arc-20160816; b=RhikadlriOC2E18TPxfA/CstKfgQW9dq0dtVt8NKyN+qP97iLJoPgYiEZRUsWZBzmW AP9b3PGF6OrMaP1Z+jk7OqY0uW+lg0WT3Nl0X+2kZe9/L1EXcNQvvJigXAT/dbASr/2O AxeeJGzosIsUF/kV+3ccqv8suQ42BnoZ3nn3y7Du+6M5PmT+fyTSuq7snY2zgOR67lM6 E8PukEwhVf0ad7F+PsgeoMkMh+EC7V5Tk4EWuNEvMlp2+veKGRg7VxK9Occx8fSjYPhC QkCU2+fkwXQH6o0xfK1vYSWZcHZgsBw4vkp2bQS6VDoGHgEAJV2zTZj6KR8aVsezaal0 hs7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=CK9wrD7qd1U+PK8BrqfAyZwrN+j+OmN8zgHfLg6j16I=; b=p9p1wjtkxdSV09NG3tDYFNWfWdAtbl1rhC9klHSdjCUG/cPfYYQC/0hGw0se+qulyJ i6opLKRUuqSTK5IdMpKj4j+wMZGUc9a9/zCiLh9wTrH+P2htJ1zOMsU1OGyZFix8vQsa mFybpc7ovE+vRX1qUn5dOofcQHGx3gwUaOqWxunBawROzZDZyFhGLtWsjriM88PYU307 XezXKpRbM1D5/mLaJ7fEBYIEcAWaLhC8VGrBeb92KZuILpNl6vRandqWAEoAQM2Lnv3g P7gnVR1XpgExpVLoMwp+ZKoWLgq4QcYd6+nVFUTVVlbdTZQtOHds5VvIlMtDHw3NXeNR 5ISg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=H1GZmPoL; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j67si1670480pgc.743.2018.02.01.08.54.01; Thu, 01 Feb 2018 08:54:16 -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=fail header.i=@infradead.org header.s=merlin.20170209 header.b=H1GZmPoL; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752936AbeBAQxC (ORCPT + 99 others); Thu, 1 Feb 2018 11:53:02 -0500 Received: from merlin.infradead.org ([205.233.59.134]:55916 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752719AbeBAQw5 (ORCPT ); Thu, 1 Feb 2018 11:52:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CK9wrD7qd1U+PK8BrqfAyZwrN+j+OmN8zgHfLg6j16I=; b=H1GZmPoLR9Jm8AmeI8XClNy7x zI2WIjC2XOr6XLwfMWgwESIIAOvjZ+vgVoTu5wDIMl9v4BhNFK6H3WdjXOdceLDLtotIbB6WG5vox 2+BXZ6ih4j8Y5iJf7k5zoBK7Sxno5btd0UzCg698u0Tkdt8XleKsNBHdVWGMaWTQv/WjIv+yFPdlE 1r0CNTkPOvDP8LMA2gzYmzzXPvqbAUMeWZfIB5bpWhOgQyDLNP0JFzdQtTLo5KnFUpzxZEjlfnQuq 8yNFHY4XJUpiTzXBYsrMiCYjdB+yo8yz8CJKhiCwQPQ2M+yJMtmB8UniJzRFuLl7ITLLyHZw8bfv/ Dq1mKFiGg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.89 #1 (Red Hat Linux)) id 1ehI6W-0007KT-N9; Thu, 01 Feb 2018 16:52:53 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id CA72F2029F9F9; Thu, 1 Feb 2018 17:52:49 +0100 (CET) Date: Thu, 1 Feb 2018 17:52:49 +0100 From: Peter Zijlstra To: Vincent Guittot Cc: Ingo Molnar , linux-kernel , Brendan Jackman , Dietmar Eggemann , Morten Rasmussen Subject: Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK Message-ID: <20180201165249.GC2269@hirez.programming.kicks-ass.net> References: <20171222075934.f6yenvcb2zkf2ysd@hirez.programming.kicks-ass.net> <20171222082915.4lcb7xyyooqyjpia@hirez.programming.kicks-ass.net> <20171222091221.ow5vn3ydx3hj4nht@hirez.programming.kicks-ass.net> <20171222185629.lysjebfifgdwvvhu@hirez.programming.kicks-ass.net> <20171222204247.kyc6ugyyu3ei7zhs@hirez.programming.kicks-ass.net> <20180115082609.GA6320@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180115082609.GA6320@linaro.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 15, 2018 at 09:26:09AM +0100, Vincent Guittot wrote: Would've probably been easier to read if you'd not included the revert of that timer patch... > @@ -9258,21 +9255,11 @@ void nohz_balance_enter_idle(int cpu) > set_cpu_sd_state_idle(cpu); > > /* > - * implies a barrier such that if the stats_state update is observed > - * the above updates are also visible. Pairs with stuff in > - * update_sd_lb_stats() and nohz_idle_balance(). > + * Each time a cpu enter idle, we assume that it has blocked load and > + * enable the periodic update of the load of idle cpus > */ > - val = atomic_read(&nohz.stats_state); > - do { > - new = val + 2; > - new |= 1; > - } while (!atomic_try_cmpxchg(&nohz.stats_state, &val, new)); > + atomic_set(&nohz.stats_state, 1); > > @@ -9422,7 +9408,6 @@ static bool nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle) > return false; > } > > - stats_seq = atomic_read(&nohz.stats_state); > /* > * barrier, pairs with nohz_balance_enter_idle(), ensures ... > */ > @@ -9432,6 +9417,16 @@ static bool nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle) > > SCHED_WARN_ON((flags & NOHZ_KICK_MASK) == NOHZ_BALANCE_KICK); > > + /* > + * We assume there will be no idle load after this update and clear > + * the stats state. If a cpu enters idle in the mean time, it will > + * set the stats state and trig another update of idle load. > + * Because a cpu that becomes idle, is added to idle_cpus_mask before > + * setting the stats state, we are sure to not clear the state and not > + * check the load of an idle cpu. > + */ > + atomic_set(&nohz.stats_state, 0); > + > for_each_cpu(balance_cpu, nohz.idle_cpus_mask) { > if (balance_cpu == this_cpu || !idle_cpu(balance_cpu)) > continue; > @@ -9441,8 +9436,10 @@ 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()) > + if (need_resched()) { > + has_blocked_load = true; > break; > + } > > rq = cpu_rq(balance_cpu); > > @@ -9477,12 +9474,12 @@ static bool nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle) > if (flags & NOHZ_BALANCE_KICK) > rebalance_domains(this_rq, CPU_IDLE); > > - if (has_blocked_load || > - !atomic_try_cmpxchg(&nohz.stats_state, &stats_seq, 0)) { > - WRITE_ONCE(nohz.next_stats, > - now + msecs_to_jiffies(LOAD_AVG_PERIOD)); > - mod_timer(&nohz.timer, nohz.next_stats); > - } > + WRITE_ONCE(nohz.next_stats, > + now + msecs_to_jiffies(LOAD_AVG_PERIOD)); > + > + /* There is still blocked load, enable periodic update */ > + if (has_blocked_load) > + atomic_set(&nohz.stats_state, 1); > > /* > * next_balance will be updated only when there is a need. After this there is no point for stats_state to be atomic anymore. Also a better name. Maybe if I drop the last two patches (and you re-introduce the bits from: Subject: sched: Optimize nohz stats, that you do need) this all becomes more readable?