Received: by 10.223.176.46 with SMTP id f43csp975375wra; Wed, 24 Jan 2018 08:42:06 -0800 (PST) X-Google-Smtp-Source: AH8x226ljz/xuhIrmAtsSdIRnWBZI5KTNBJTFWcIU+40RWV6vupz8G9rFkH1vxuourxy0t/YKPBI X-Received: by 10.99.127.79 with SMTP id p15mr11142184pgn.140.1516812126135; Wed, 24 Jan 2018 08:42:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516812126; cv=none; d=google.com; s=arc-20160816; b=Xso6DGPUt6nQer/U2YOjVbjn2SE/ClIDA4yTHXLyaq/OHq6Wi/NPui/O5ys33SaFhr jTv42aDDU7za9ctdcDjNGWH68/LBjLV/YpnNou3CYZLwI0F+OaGuRY9Cc3wiasY9yQEJ EsPO5UjTkZLCW3nyDidxGqEY9EZA3+mSbRFnJqkP5U2HUj9rq84R6DwJOTNjsSTOCEFG MVstGOP7IJ0A12AlpdPPi5Irj1fZR8Dx0T+MWYM4h2GnjbpAulWo+ADqMA1T2mr59Udj laiTdSDMnF8zopXUFSLf+OCS6g389kNC2NqgcFTkNqPRnHhrBZcnQcuS94dmnMz7DbjL ubYA== 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=EHReFy6UXrmxsui3fw1luCDAoSWySOw69GXMBjm/vf0=; b=diaqNKSkrzYUVQVZa3hOTT1eVZx3bJ+T8qw5RI3wXMjXZBTZpONrJ90SfVHwcCPAja ql1ioyI/8e5ktZnkAHvm/ZZB4kJClyqwL6SFLm3ogqBgk2G7DcWosFWl9o8XCssUafEY yKxb8AaBPFw3rkQoSFBRRjxqzQftCS1iJfhAuagJFJQkAdWUywbKe7bz3F7wfL3s5rWj 9gm7QLSP8NR55znfAJwYv5xOQcTEY7hSEubJOuK2yjHmugZxSDIRp2LYRrLJx3T0DHFV MYqpgBBThaBXCrCpLPJBkXyJtGsaGqWC0UNiiH3orlr+AtF2VQzaxIsuw2HcR5m5VYog RY/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YgwGVQf3; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z20-v6si442642plo.73.2018.01.24.08.41.51; Wed, 24 Jan 2018 08:42:06 -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=@google.com header.s=20161025 header.b=YgwGVQf3; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964826AbeAXQkL (ORCPT + 99 others); Wed, 24 Jan 2018 11:40:11 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:35483 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934296AbeAXQkI (ORCPT ); Wed, 24 Jan 2018 11:40:08 -0500 Received: by mail-it0-f66.google.com with SMTP id e1so5898340ita.0 for ; Wed, 24 Jan 2018 08:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EHReFy6UXrmxsui3fw1luCDAoSWySOw69GXMBjm/vf0=; b=YgwGVQf3wujLD/7OjL0pTofEWSdNWsyFGCkXiSkmNnKeGuqrIAP0tCcC7n59Xubmf2 U6AV4aZcuh95//PBrzC62eminic/Ut0lSjy8crUJOpGSWvrDMFELPYOq37D0+2UZdvXu KxQ1+x7AxyMCh3pKImQtv3j30r8ZrWsRg2ifJJdHCqf51E6ERBC2DtHT/pxYuhxPHDkU H4ze/jnzXI5rAOaiF3jh+OI7cDn7WBG2VJJmnIrOnbvacd6pWlS3zNUic+jS8fcl6+EH 5l9VOdT0AAe4HMyQs47sv9HALttH1STtoT9GeZnb2FrHrlNAINm8NBjvzeJAurrSmz4T esWw== 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=EHReFy6UXrmxsui3fw1luCDAoSWySOw69GXMBjm/vf0=; b=KBSYtYjFKUuxjXIQX5k0QpN1xjMMSVzSZQQhd17G9F0xgyYMm5yAZhQ4yrhvboAPQm zO5zhneYVfzBND6msgp7Ei6D8uAU5FHRfsLOBgww6SbcGad5oJxCUClixCVn8VeYLaJ6 V9CANSPPUSRhK46tJksKuNSdETGYzh3kkWnk+NC5Qa3YozHpem2HaDNSEsqMnkQ6AHp0 WUBgsIo3dBgiwXBrTHoIQAr/PENpakhwjf9LlCS1o2rpYBFzqMxmOQfX1fE0KMDc8LCa Mhk7zf3RQ6fPtkQWWNUoxu8tzBlqkMfO/OJ0ZGGJrcRvYiU5zrsKtExE85ohz2rgS9IW V84Q== X-Gm-Message-State: AKwxytccQi0CqSAJGBhwfDtR863Lel1wgM9TheCQrbGrI2yzYQ5XvN82 hzAAxhxekLLR3WUAJzmVOj/xy/QsEruNLJAgUR6X7Q== X-Received: by 10.36.166.67 with SMTP id r3mr9092821iti.33.1516812007948; Wed, 24 Jan 2018 08:40:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.172.135 with HTTP; Wed, 24 Jan 2018 08:40:07 -0800 (PST) In-Reply-To: <20180123180847.4477-2-patrick.bellasi@arm.com> References: <20180123180847.4477-1-patrick.bellasi@arm.com> <20180123180847.4477-2-patrick.bellasi@arm.com> From: Joel Fernandes Date: Wed, 24 Jan 2018 08:40:07 -0800 Message-ID: Subject: Re: [PATCH v3 1/3] sched/fair: add util_est on top of PELT To: Patrick Bellasi 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 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 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? I went through previous conversations and couldn't find a reason, if I missed something I appreciate if you can explain the rationale. thanks, - Joel