Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3413346imm; Mon, 4 Jun 2018 03:14:49 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ8Mj282rfGGtncX+XDSZ8oKfx144+Rdp/5LbWq4O801TZpvp58IqROQ3ALxYgl8jJJb4KF X-Received: by 2002:a17:902:2826:: with SMTP id e35-v6mr21198361plb.348.1528107289779; Mon, 04 Jun 2018 03:14:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528107289; cv=none; d=google.com; s=arc-20160816; b=hXAdwjFv3mA+Pr3rGVgV5wNOxxRFXj0g0mE7LW76IUNiUa7vGXyn+kc0SyzmnyiRbd fhgYPKrrB4fJVBaNU1+8qBDWQRbynDQZOB/h2jJRcaPHaE0B7CWs5QDQXk+931fWJ1IE s9dzFVwQQFPy0LFrMa3efZ1KA2EZiPQGX5wrFIBbmRX0OR+mwoaxJnRUhWhwkGoFD+sh H2yW/fH3C8g7wP9Df1N3qDq+jG4UJLquodiUJ0PtSvoqfopQxn/W+w7wD7FV12yEf2TX yKUT03qvBrVTyUVSAkjCde+ulF+6PPiZL0sGYcj5ynmqljPi78u0vTYMPArukTc3+1lZ 7vLA== 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=CFolD9rc/Zy/Iz8r5qlQNnAI+ro0l0WQWl/wsuJD5cA=; b=c1/vcgoXXQSYBU0AMz0OYLsHIEXlM3phtxBEWda322NijjII/QqrPn8i5Wmh9p8chx Dfd+nMl5VVJB3J97k3xigVmMEgaduSDtnMbsS9LCCQ7w0AIh0vFDCPpFP4/OnutGv4Hc diNICnaTLbhKk2Q3PTrpjxAAxrGY09UTC+J9oQ4PmttoagW+e3X43M0oikWXpaMHGYV8 n3AuyWg+hDnjbCwp1lXHmy/TRwlhyvgr5wLmpByNHyzEGqasfGNTqoGg2U9iKXrX5kPx xqdrQzMu4d7cdDQbS4vmwk87kPXIvcWHkgvGlZ5329P2fa0sfStJzHxWGvv+jA8QXUS0 sz2g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v61-v6si46606002plb.499.2018.06.04.03.14.35; Mon, 04 Jun 2018 03:14:49 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752487AbeFDKMx (ORCPT + 99 others); Mon, 4 Jun 2018 06:12:53 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:39088 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751989AbeFDKMw (ORCPT ); Mon, 4 Jun 2018 06:12:52 -0400 Received: by mail-wm0-f65.google.com with SMTP id p11-v6so13223525wmc.4 for ; Mon, 04 Jun 2018 03:12:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=CFolD9rc/Zy/Iz8r5qlQNnAI+ro0l0WQWl/wsuJD5cA=; b=c+D3ixjN33t1YZfVqMwnlZtS18Kpil64CT5Bko1rntPEKrxkgS3O4DyzBhpyfoPYrC 2f4ooA8orUxlPOP+2tLp2WZIUwHrFnkIdveZK4mCRoveqRBt9xJ/zeDAb3GjCiLsE8xu oL/gQb1SbZytCtDYKPKrLK5uZuJXAmM7srzBpWIm2FwF6xBE70fuuhCikYG5vgl2zvoC a/aVqJV1+N2FyhauU+suvA3F0XCGo3Ajg6uPe4v3+7bbBgfc3oGm6O+FUIPN4wUnccg8 D+Ny/DACNQL3RJCgiF0SShVAIQqCI5CNF8CmICmzRs+k7BO8m2F7tb6Urivyye8XdLEY 4QIQ== X-Gm-Message-State: ALKqPwefwNXAp4bQanP9db0qdz6zO1mF+QS9JR9J9bRjQWP1nhRTOf59 xNVPw/QOMANlpmBMNlBuxsU50w== X-Received: by 2002:a1c:ec0a:: with SMTP id k10-v6mr8075628wmh.4.1528107170771; Mon, 04 Jun 2018 03:12:50 -0700 (PDT) Received: from localhost.localdomain ([151.15.207.242]) by smtp.gmail.com with ESMTPSA id e2-v6sm633841wro.97.2018.06.04.03.12.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Jun 2018 03:12:49 -0700 (PDT) Date: Mon, 4 Jun 2018 12:12:47 +0200 From: Juri Lelli To: Vincent Guittot 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 Subject: Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization Message-ID: <20180604101247.GB2731@localhost.localdomain> References: <20180528152243.GD1293@localhost.localdomain> <20180531102735.GM30654@e110439-lin> <20180601135307.GA28550@linaro.org> <20180601174526.GA105687@joelaf.mtv.corp.google.com> <20180604070438.GA2731@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/06/18 09:14, Vincent Guittot wrote: > 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 OK. > Then, we can't do that in a current signal. So you would like to add > another metrics in cfs_rq ? Since it's CFS related, I'd say it should fit in CFS. > 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 Mmm, can't we distinguish in, say, pick_next_task_fair() if prev was of higher prio class and act accordingly? Thanks, - Juri