Received: by 10.192.165.156 with SMTP id m28csp873387imm; Wed, 11 Apr 2018 08:33:13 -0700 (PDT) X-Google-Smtp-Source: AIpwx49qYjl02KDCjobUnApWf8JcBhk4ZI1QSktAXCM3VcHmxMNpE1emA/N0giNg+djPKyceToE/ X-Received: by 2002:a17:902:9a96:: with SMTP id w22-v6mr5499150plp.209.1523460793355; Wed, 11 Apr 2018 08:33:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523460793; cv=none; d=google.com; s=arc-20160816; b=pm9pyB0X8B8gmB/Uowv+EIiEaamblvz/H35KAEECvRKLQj6uQbUUvdWoL3QrIuMGRT i/5CDl6xp8WTC0Iw7uLZ1BACIVpS9avgVjBkOm2+gGmwuY/q4zz4Hr4kG2UBt3B7aXQ7 G0BEj20bUYxh1lIEFKBlMNBF+t/V7JF5JZvDly8pIEgNzMG3D6i9ig02OHOT8XSFK/Es gXB/UGnwDdWOmRny5ZUzKLbPsNECRQfds4yB3KIpavLw2J+S2QbBi9AYsrm50K0MqVVp bHU0SF+eVKmVtE87o3bN4doI5gb6EvWTA6J8gjOBQR4rYSZlIwfM4zl4TpeOifaTNZIB 1hNA== 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=w6HA5mAbFeMni6BofHWHbaLeSSOd7DUsKFOzfDEl3wI=; b=SMTFErgjIPMxyEVyjCK72+ogPTv7ZRlZ1N4S/6gHgG/yNczH3O8vo1q7B7/TOHYA70 Na62J0nrI/XRxBv4c1N4ZW6M/hIjDk+HzXL8lEBGS/zFrVhMLPx9B5QxoZyNJJdsQRtC xXVV27pTkJJRLqD5e3yAnsk1hORw3HWOy4umDbGih9gIbEAaBnUE5+85sn07xrA3V+Iu kP05YrQ2R75gR00jPo7x8CrOv5P2Lk8Su5tZcIkG7MBSv7MwluUsS00rjSSXikITwngE MpBWuprHIoujzN8wk+jGHcnp+DpEvpLwpAQcQ3kYSAdtGIS+ZyBj5xzEVy2iAmhhHwvI ivDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=M0Enzu6S; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w18si922348pgm.284.2018.04.11.08.32.36; Wed, 11 Apr 2018 08:33:13 -0700 (PDT) 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=@linaro.org header.s=google header.b=M0Enzu6S; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753690AbeDKP3Y (ORCPT + 99 others); Wed, 11 Apr 2018 11:29:24 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:38141 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753592AbeDKP3W (ORCPT ); Wed, 11 Apr 2018 11:29:22 -0400 Received: by mail-io0-f172.google.com with SMTP id b20so2816182iof.5 for ; Wed, 11 Apr 2018 08:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w6HA5mAbFeMni6BofHWHbaLeSSOd7DUsKFOzfDEl3wI=; b=M0Enzu6Ss11Uc4ysGSD6KgUD970kcYvA/ml715dXc5OvfjNAL5Gk9UF9xex6HGsEWK +B6zSUayh2Dj6Ned/Rew8fiYcDzqkM40e4MnFglPabcVQC5/cFspMhK88qrMd5HOzg+A Q290fN177SrQWOal+xTtqmzx3M+V4Hz9AKLtI= 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=w6HA5mAbFeMni6BofHWHbaLeSSOd7DUsKFOzfDEl3wI=; b=LKbSspLrI4vQtEKZ7/cTyD1FEdp4ICifpuzhgfsZ0GNear0sApXtzjDWcqNC3cS3aE OB0XthDSEK9313GUkOLX3gBw8bcewhxPRFDuVMw/DJNYfx4EQjB8iqfYny510Nkh5uST sLkusRCdjjt4D9wYStwxg3ZePh/cSGD5qeylb3RnQYACxwxqn+YlKVo87+nN+xYESAcp nE1m+YUPIdTX1/hPr+wD+e/ymKdrJvSoH9fR8J741fjrgoxLATaa4KI8Yyzn6bHSE7LL jveObutU7K+JYV38UjhQcoTXOt+xNU8nFPFkz5RuBK4FXWn5gB2lusgmrOIxnj8lROe4 8WOw== X-Gm-Message-State: ALQs6tA09dRvbKz2W0BSIoFC/+tILDzOTcMW0OrrUwqmGoi5iX4EvNTS zVI2h65Kzxfl8a3D0n4I6+2RxH4ZUCGm0C2GYrcYmg== X-Received: by 10.107.149.208 with SMTP id x199mr5444607iod.196.1523460562036; Wed, 11 Apr 2018 08:29:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.222.20 with HTTP; Wed, 11 Apr 2018 08:29:01 -0700 (PDT) In-Reply-To: <20180411151450.GK4043@hirez.programming.kicks-ass.net> References: <20180406172835.20078-1-patrick.bellasi@arm.com> <20180410110412.GG14248@e110439-lin> <20180411151450.GK4043@hirez.programming.kicks-ass.net> From: Vincent Guittot Date: Wed, 11 Apr 2018 17:29:01 +0200 Message-ID: Subject: Re: [PATCH] sched/fair: schedutil: update only with all info available To: Peter Zijlstra Cc: Patrick Bellasi , linux-kernel , "open list:THERMAL" , Ingo Molnar , "Rafael J . Wysocki" , Viresh Kumar , Juri Lelli , Joel Fernandes , Steve Muckle , Dietmar Eggemann , Morten Rasmussen 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 11 April 2018 at 17:14, Peter Zijlstra wrote: > On Tue, Apr 10, 2018 at 12:04:12PM +0100, Patrick Bellasi wrote: >> On 09-Apr 10:51, Vincent Guittot wrote: > >> > Peter, >> > what was your goal with adding the condition "if >> > (rq->cfs.h_nr_running)" for the aggragation of CFS utilization >> >> The original intent was to get rid of sched class flags, used to track >> which class has tasks runnable from within schedutil. The reason was >> to solve some misalignment between scheduler class status and >> schedutil status. >> >> The solution, initially suggested by Viresh, and finally proposed by >> Peter was to exploit RQ knowledges directly from within schedutil. >> >> The problem is that now schedutil updated depends on two information: >> utilization changes and number of RT and CFS runnable tasks. >> >> Thus, using cfs_rq::h_nr_running is not the problem... it's actually >> part of a much more clean solution of the code we used to have. >> >> The problem, IMO is that we now depend on other information which >> needs to be in sync before calling schedutil... and the patch I >> proposed is meant to make it less likely that all the information >> required are not aligned (also in the future). > > Specifically, the h_nr_running test was get rid of > > if (delta_ns > TICK_NSEC) { > j_sg_cpu->iowait_boost = 0; > j_sg_cpu->iowait_boost_pending = false; > - j_sg_cpu->util_cfs = 0; > > ^^^^^^^^^^^^^^^^^^^^^^^ that.. > > - if (j_sg_cpu->util_dl == 0) > - continue; > } > > > because that felt rather arbitrary. yes I agree. With the patch that updates blocked idle load, we should not have the problem of blocked utilization anymore and get rid of the code above and h_nr_running test