From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754217AbbGUKaC (ORCPT ); Tue, 21 Jul 2015 06:30:02 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:34576 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753732AbbGUKaA (ORCPT ); Tue, 21 Jul 2015 06:30:00 -0400 Date: Tue, 21 Jul 2015 18:29:56 +0800 From: Boqun Feng To: Yuyang Du Cc: mingo@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, pjt@google.com, bsegall@google.com, morten.rasmussen@arm.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, umgwanakikbuti@gmail.com, len.brown@intel.com, rafael.j.wysocki@intel.com, arjan@linux.intel.com, fengguang.wu@intel.com Subject: Re: [PATCH v10 6/7] sched: Provide runnable_load_avg back to cfs_rq Message-ID: <20150721102956.GA5380@fixme-laptop.cn.ibm.com> References: <1436918682-4971-1-git-send-email-yuyang.du@intel.com> <1436918682-4971-7-git-send-email-yuyang.du@intel.com> <20150721010346.GA2882@fixme-laptop.cn.ibm.com> <20150721004400.GA28512@intel.com> <20150721101845.GB2882@fixme-laptop.cn.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <20150721101845.GB2882@fixme-laptop.cn.ibm.com> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2015 at 06:18:46PM +0800, Boqun Feng wrote: > On Tue, Jul 21, 2015 at 08:44:01AM +0800, Yuyang Du wrote: > > On Tue, Jul 21, 2015 at 09:08:07AM +0800, Boqun Feng wrote: > > > Hi Yuyang, > > >=20 > > > On Wed, Jul 15, 2015 at 08:04:41AM +0800, Yuyang Du wrote: > > > > The cfs_rq's load_avg is composed of runnable_load_avg and blocked_= load_avg. > > > > Before this series, sometimes the runnable_load_avg is used, and so= metimes > > > > the load_avg is used. Completely replacing all uses of runnable_loa= d_avg > > > > with load_avg may be too big a leap, i.e., the blocked_load_avg is = concerned > > > > to result in overrated load. Therefore, we get runnable_load_avg ba= ck. > > > >=20 > > > > The new cfs_rq's runnable_load_avg is improved to be updated with a= ll of the > > > > runnable sched_eneities at the same time, so the one sched_entity u= pdated and > > > > the others stale problem is solved. > > > >=20 > > >=20 > > > How about tracking cfs_rq's blocked_load_avg instead of > > > runnable_load_avg, because, AFAICS: > > >=20 > > > cfs_rq->runnable_load_avg =3D se->avg.load_avg - cfs_rq->blocked_load= _avg. > >=20 > > No, cfs_rq->runnable_load_avg =3D cfs_rq->avg.load_avg - cfs_rq->blocke= d_load_avg, > > without rounding errors and the like. > > =20 >=20 > Oh, sorry.. yeah, you're right here. >=20 The point is that you have already tracked the sum of runnable_load_avg and blocked_load_avg in cfs_rq->avg.load_avg. If you're going to track part of the sum, you'd better track the one that's updated less frequently, right? Anyway, this idea just comes into my mind. I wonder which is udpated less frequently myself too. ;-) So I ask to see whether there is something we can improve. Regards, Boqun --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJVrh8hAAoJEEl56MO1B/q4RkQH/28ZoWXO1fCxrnE6CuxRoch1 2QrKZ/ZuQbCajOhSXlfB2lxfRdCLL/ZUUIYfMV2W9c60MLoKBnpZDQqY+m5GZvwM jIk88kf5odPCkZlWXYjHgR9YouHXjE7z8mOkcP3wlL0DUhD/GPRpYOnM0ADsyvEL Z6kGAHG3GM93b5LruH9ny8L33ufvr23JHcRHdlYcu+m8tzGAkCjLmOBe1plrL+em EqV1UJCtkuK5GDl795FIUyuIsB09T4xrVXI6B1rNySqFzkxmQlBvrdObgONB/wuU 6c6a62RAG/D655byQHsCEb3mWkzDiteBJLf4CcMPYQ7GW66korRP2mYDgjV03hY= =51Wp -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--