Received: by 10.223.176.46 with SMTP id f43csp1140284wra; Wed, 24 Jan 2018 11:17:02 -0800 (PST) X-Google-Smtp-Source: AH8x224jHPOfTS4Sh9J/YsNfGX7GJiUJchWA70Ydx38mcquFocUIHYYX/qK+eZja89zldkjl069e X-Received: by 2002:a17:902:9897:: with SMTP id s23-v6mr8836584plp.238.1516821422501; Wed, 24 Jan 2018 11:17:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516821422; cv=none; d=google.com; s=arc-20160816; b=uhZFbbqF7c2IUWLHa0TzU7GfD4U9iq5z/Mv1mcZft1ek5mAV86y1JQm7Wjz0SYqsrt 2YCZQzEY1w7h7E4TRa2BPXEziqTa4aSUohrjF1gqM+mDuZBttbwA55qFWC7US+17aKk6 0EUiBwbxYDCjxeZw6YuWWbmLVrFVa0bTn9Ooa0GES+KR8tBn0Axm7JHi5nHVD6LuU2Id gp5k2qrVEOZUVCl3HLHorFn56SbhCYFO2kIh45ZuMnCqZ8ygue8KfWus0ZmdYUgi+LSG sD2dSzx0SFxIO8iWg6ftrlvUUseyTcdw+BoKaySLUDECn6ZjncsUA/BRoq77h0I1Jbyq ZPoA== 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:arc-authentication-results; bh=tj1Ck3zpqmyOqZgdWSXvkhdVd0dGh5frbmDWSBrEVCg=; b=0Qv3gsaveFD53PRi9bOJaM6vXzA8YS2+Lpd2LpS4pgn47X/dk7q/wElKF/0VD1U8Ko bs0A34Oc0LR3fw7mENFJDZjSoLi1godOPjWK0xQi1TVsv0uqaI8FkaIo4BIwKnG/Gvnc hBDIhulmT8RfjwSPY6JU4/BO6vyLTOUpVmaINDZ37HGk6/VAhtDKFQocFxRnUZpy+/p0 8PHIBscqTDjogcHwjACrmakNtS9wdIjEcTXpe/vnHz6vvyhXQyBYlqa6a02cUcry6Yut of/3bJJdXLRPBomavYNZfzSx2kha7IP5IkiyfycRFoSGWVfkFZ8SSEL5UwW4jPteQrRr 2JeQ== ARC-Authentication-Results: i=1; mx.google.com; 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 a10-v6si629511pln.370.2018.01.24.11.16.48; Wed, 24 Jan 2018 11:17:02 -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; 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 S965130AbeAXTQU (ORCPT + 99 others); Wed, 24 Jan 2018 14:16:20 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56782 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964999AbeAXTQS (ORCPT ); Wed, 24 Jan 2018 14:16:18 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A2E5815A2; Wed, 24 Jan 2018 11:16:17 -0800 (PST) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 47E9F3F318; Wed, 24 Jan 2018 11:16:15 -0800 (PST) Date: Wed, 24 Jan 2018 19:16:09 +0000 From: Patrick Bellasi To: Joel Fernandes Cc: LKML , Linux PM , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Steve Muckle Subject: Re: [PATCH v3 1/3] sched/fair: add util_est on top of PELT Message-ID: <20180124191609.GA5739@e110439-lin> References: <20180123180847.4477-1-patrick.bellasi@arm.com> <20180123180847.4477-2-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24-Jan 08:40, Joel Fernandes wrote: > On Tue, Jan 23, 2018 at 10:08 AM, Patrick Bellasi > wrote: > > The util_avg signal computed by PELT is too variable for some use-cases. > > For example, a big task waking up after a long sleep period will have its > > utilization almost completely decayed. This introduces some latency before > > schedutil will be able to pick the best frequency to run a task. > [...] > > -static inline unsigned long task_util(struct task_struct *p); > > static unsigned long cpu_util_wake(int cpu, struct task_struct *p); > > > > static unsigned long capacity_spare_wake(int cpu, struct task_struct *p) > > @@ -6262,6 +6337,11 @@ static inline unsigned long task_util(struct task_struct *p) > > return p->se.avg.util_avg; > > } > > > > +static inline unsigned long task_util_est(struct task_struct *p) > > +{ > > + return max(p->se.avg.util_est.ewma, p->se.avg.util_est.last); > > +} > > + > > /* > > * cpu_util_wake: Compute cpu utilization with any contributions from > > * the waking task p removed. > > diff --git a/kernel/sched/features.h b/kernel/sched/features.h > > index 9552fd5854bf..c459a4b61544 100644 > > --- a/kernel/sched/features.h > > +++ b/kernel/sched/features.h > > @@ -85,3 +85,8 @@ SCHED_FEAT(ATTACH_AGE_LOAD, true) > > SCHED_FEAT(WA_IDLE, true) > > SCHED_FEAT(WA_WEIGHT, true) > > SCHED_FEAT(WA_BIAS, true) > > + > > +/* > > + * UtilEstimation. Use estimated CPU utilization. > > + */ > > +SCHED_FEAT(UTIL_EST, false) > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > > index 2e95505e23c6..0b4d9750a927 100644 > > --- a/kernel/sched/sched.h > > +++ b/kernel/sched/sched.h > > @@ -470,6 +470,7 @@ struct cfs_rq { > > * CFS load tracking > > */ > > struct sched_avg avg; > > + unsigned long util_est_runnable; > > Since struct sched_avg would now have util_est, cfs_rq gets it too. > Then can we not try to reuse that struct and avoid having to expand > cfs_rq more than needed? Yes, that's possible now... the main issue is that for RQ's we do not track an EWMA, but still we can use the util_est::last field or maybe use a union just to use a better name when used from the RQ side. > I went through previous conversations and couldn't find a reason, if I > missed something I appreciate if you can explain the rationale. I've used a separate filed just because SE's util_est was not part of sched_avg, and missed the opportunity to consolidate better this now that we moved it. Thanks for pointing this out ;-) > > thanks, > > - Joel Cheers Patrick -- #include Patrick Bellasi