Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755995AbdLOOIC (ORCPT ); Fri, 15 Dec 2017 09:08:02 -0500 Received: from merlin.infradead.org ([205.233.59.134]:45006 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755322AbdLOOIB (ORCPT ); Fri, 15 Dec 2017 09:08:01 -0500 Date: Fri, 15 Dec 2017 15:07:51 +0100 From: Peter Zijlstra To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes Subject: Re: [PATCH v2 2/4] sched/fair: add util_est on top of PELT Message-ID: <20171215140751.3ajilhsmj4zhzhzy@hirez.programming.kicks-ass.net> References: <20171205171018.9203-1-patrick.bellasi@arm.com> <20171205171018.9203-3-patrick.bellasi@arm.com> <20171213160537.uqa423dyt5wrpgll@hirez.programming.kicks-ass.net> <20171215140218.GC19821@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171215140218.GC19821@e110439-lin> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1278 Lines: 34 On Fri, Dec 15, 2017 at 02:02:18PM +0000, Patrick Bellasi wrote: > On 13-Dec 17:05, Peter Zijlstra wrote: > > On Tue, Dec 05, 2017 at 05:10:16PM +0000, Patrick Bellasi wrote: > > > + if (cfs_rq->nr_running > 0) { > > > + util_est = cfs_rq->util_est_runnable; > > > + util_est -= task_util_est(p); > > > + if (util_est < 0) > > > + util_est = 0; > > > + cfs_rq->util_est_runnable = util_est; > > > + } else { > > > > I'm thinking that's an explicit load-store to avoid intermediate values > > landing in cfs_rq->util_esp_runnable, right? > > Was mainly to have an unsigned util_est for the following "sub"... > > > > That would need READ_ONCE() / WRITE_ONCE() I think, without that the > > compiler is free to munge the lot together. > > ... do we still need the {READ,WRITE}_ONCE() in this case? > I guess adding them however does not hurts. I think the compiler is free to munge it into something like: cfs_rq->util_est_runnable -= task_util_est(); if (cfs_rq->util_est_runnable < 0) cfs_rq->util_est_runnable = 0 and its a fairly simple optimization at that, it just needs to observe that util_est is an alias for cfs_rq->util_est_runnable. Using the volatile load/store completely destroys that optimization though, so yes, I'd say its definitely needed.