Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3277417imm; Mon, 4 Jun 2018 00:15:57 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIxBbG6QXc3NqTe5GDgfU893rduABtc82TfJG2MfJjzLTrnTfVYj7D0GtvjkbyzoBdoavpk X-Received: by 2002:a63:7209:: with SMTP id n9-v6mr16409849pgc.146.1528096557399; Mon, 04 Jun 2018 00:15:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528096557; cv=none; d=google.com; s=arc-20160816; b=MYRXCt05N9XmOIGlRF9f+Y2WUqg8+3A67PKBttUiqjrSJZpnAf+837bipolQ/ebrvE ECT0MjjOL7QbGABuKG15z9rNNVBUao4U2e2ovEgRuB0zoTbSJTP+XgiKwZ8XuQShVHRa L5msyj13OmlunvF/wkMLazTqHFctRtGhAlwqfjTmYIYYuF+rIEcbSz+uf1VPBPBvTPVF +h3sqMK1L4rj1EOT5X8Uide7FrdRn2bK4sYYml91JzptJwa/dZVh+9ZPu3xx4yu764u5 FlO2efx3CnqVwbrL+1pRb70mMX2ZFSLIgLKbtd5eLBh+3kTYTtAV9pwC5SiQ5bwSJUNT gT6Q== 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=csSbf7ajqw7uh9hlJONi58i0LxwRDjTyvuz3gS59Evg=; b=ukFiZ9F2CNgdEKOMWzC5ucB7dW5wKgZwhYHh6yIJ6kWBoBQ+VDRTtstdqu9ygVv/kr Ko6+M9HLATHKywsiGfFMqBR75SsgG4bA5WemmcDQfXR4NRmUIRa0HZXq5B9nxo/c1eRf hdssqcAHqZ4DmsnlH151VywRqdmwZlgcIXygF+cvLYVepPry3It1Tz9FUUuua/0XNJyl fHYDkbkzUDzqxxJf9CK/Zl3Sr9e18AgzYYi4HrtYzkna4k0NMUdXZ2d1NAXoE52rFxs9 rmwZ3JyI6nyb9JvgTIfcqh4kPrDAidFJjOvQkRGFcAWq+33rpXYblu72kMgLmrP0+lGS aI0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LQM2/B8j; 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 o1-v6si32123896pga.261.2018.06.04.00.15.42; Mon, 04 Jun 2018 00:15:57 -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=LQM2/B8j; 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 S1753739AbeFDHPT (ORCPT + 99 others); Mon, 4 Jun 2018 03:15:19 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:52826 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752250AbeFDHPQ (ORCPT ); Mon, 4 Jun 2018 03:15:16 -0400 Received: by mail-it0-f67.google.com with SMTP id m194-v6so8891161itg.2 for ; Mon, 04 Jun 2018 00:15:16 -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=csSbf7ajqw7uh9hlJONi58i0LxwRDjTyvuz3gS59Evg=; b=LQM2/B8jBVkInbMBROtX4WO/qQFv5ms7jiUlV1DmadEZ87lWjU/k3da6tSIhwa1jPS Snhsgf65wPHuJLg5hccNMEd7BXbeeqRwOitggZpOivxoeI5smfBJzUZwV1sTvx6hA7cc fRHxITCP5FCuFiJef3oj8FuIfmgwjUjPDt0/w= 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=csSbf7ajqw7uh9hlJONi58i0LxwRDjTyvuz3gS59Evg=; b=hDM2p3NZ1/TvZyTWNEaVsUSwnK4gz2MEcm7M+jEG2gQGfav0u/XnhkySI+hBsZyvuU DuCHbpHWpeYr9BzT+1WEu4Aw2ItzxQOVGFbv61Rk1TcRSafnjfYcWnu/JCrGOAKgbkwM 9GkZsqwZVayfODW/NGB6VUR4NWbfMpkPnRW4Rr6uY+SFbIzU2aeajRheJAZ8/aCOmnN/ nvZC5237e+NZPA8QQ8nGpK9pgUMRToz0dbo57xoq28UMmACdgSsGqHhiD7LCMraSBsWR 270ipsMuOD6qtx8x++blqzpXqEqetn+g+Rk7vzFgU7ByR7fki5z+aaO7XfdUfy1HfW9a a+ew== X-Gm-Message-State: APt69E046IABDEQpb9L+5r5Kp15x09cc5lcjLre71uXLZLw+m4h0sSWf ORm/knhBoV87+uJSko9qPnKSNpI2h1jwYWTxzaCDBA== X-Received: by 2002:a24:f987:: with SMTP id l129-v6mr13134504ith.148.1528096516107; Mon, 04 Jun 2018 00:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:304a:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 00:14:55 -0700 (PDT) In-Reply-To: <20180604070438.GA2731@localhost.localdomain> References: <1527253951-22709-6-git-send-email-vincent.guittot@linaro.org> <20180528101234.GA1293@localhost.localdomain> <20180528152243.GD1293@localhost.localdomain> <20180531102735.GM30654@e110439-lin> <20180601135307.GA28550@linaro.org> <20180601174526.GA105687@joelaf.mtv.corp.google.com> <20180604070438.GA2731@localhost.localdomain> From: Vincent Guittot Date: Mon, 4 Jun 2018 09:14:55 +0200 Message-ID: Subject: Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization To: Juri Lelli Cc: Joel Fernandes , Patrick Bellasi , Peter Zijlstra , Ingo Molnar , linux-kernel , "Rafael J. Wysocki" , Dietmar Eggemann , Morten Rasmussen , viresh kumar , Valentin Schneider , Quentin Perret , Luca Abeni , Claudio Scordino , Joel Fernandes , "Cc: Android Kernel" , Alessio Balsini 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 4 June 2018 at 09:04, Juri Lelli wrote: > Hi Vincent, > > On 04/06/18 08:41, Vincent Guittot wrote: >> On 1 June 2018 at 19:45, Joel Fernandes wrote: >> > On Fri, Jun 01, 2018 at 03:53:07PM +0200, Vincent Guittot wrote: > > [...] > >> > IMO I feel its overkill to account dl_avg when we already have DL's running >> > bandwidth we can use. I understand it may be too instanenous, but perhaps we >> >> We keep using dl bandwidth which is quite correct for dl needs but >> doesn't reflect how it has disturbed other classes >> >> > can fix CFS's problems within CFS itself and not have to do this kind of >> > extra external accounting ? > > I would also keep accounting for waiting time due to higher prio classes > all inside CFS. My impression, when discussing it with you on IRC, was > that we should be able to do that by not decaying cfs.util_avg when CFS > is preempted (creating a new signal for it). Is not this enough? We don't just want to not decay a signal but increase the signal to reflect the amount of preemption Then, we can't do that in a current signal. So you would like to add another metrics in cfs_rq ? The place doesn't really matter to be honest in cfs_rq or in dl_rq but you will not prevent to add call in dl class to start/stop the accounting of the preemption > > I feel we should try to keep cross-class accounting/interaction at a > minimum. accounting for cross class preemption can't be done without cross-class accounting Regards, Vincent > > Thanks, > > - Juri