Received: by 10.192.245.15 with SMTP id i15csp1114819imn; Sun, 11 Mar 2018 03:22:07 -0700 (PDT) X-Google-Smtp-Source: AG47ELvmbGD24xK8DJbcpPy0HHd9vsLGNpxNn0DvtLeRksY79lO7QN2zfYwsDtzneGY1HPv9SqZ/ X-Received: by 2002:a17:902:2de4:: with SMTP id p91-v6mr4420278plb.405.1520763727865; Sun, 11 Mar 2018 03:22:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520763727; cv=none; d=google.com; s=arc-20160816; b=hyqM68k7ZTcq5cQ68hTbmhrT+KwEl4Ptlh3FogM6lOOncZ3uEl8le0aZWzrQfod93X it2tKjNXtGi5MCyKbX6MCAggRv4/GTlohqcYnZDJGfGdkGER8td2xquPKgkPHd2wwl1z dCkZS2KChIJwuR/KNTAsll1Czr2j5aN2TXTjjoH0p2+J7qSOOvyBFrm/E15UAs1Vr7LE l9z38DZdvCVYRhrebNh+HAUuRsEo2o0VAJVGyYCfCdFtelOA5r9pLOT+kBExvninKNg3 PiqScnW/AQRIVgh1Cj1e7hb30w+pT50cyQsJ08gBqFcmDrh4PLGuntBYmk8+PQ++hDl2 RLOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=LVpLXVnZiho56O82pxBvGLHQ4tozvRAOw8Nc4uDvuKI=; b=gV9+pXTev2aZ3Vs1c+cSvKS3d59uYodifARKgu8SO01lyB0RZjC9tFV6JyHdyfHvGs 7xBSt3TwCv1EM2Le0XcbqCiBwSbWH4z3E6K2anbeX3s0pa1ALtFOQZrjed67g7VtT2Gx i0N2gftt9SyWep+hueR5hO7wcallzzypaR54WqZ5CKH401So8OYJzZdd1ZujqtBIIgoJ bK8jaraPzHnMC4han8IXI0LG2SgcmzFEwJp8DdNtdNJ211IhmS4Mp9iTtFHsU/FaD009 oV9CnKZtUCQprvLciWMUSTpmrptJRR4jDQqnfh70Beludmus6R3Mrp65w0oSrpkmG87h c+QA== 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 e4si3476906pgv.581.2018.03.11.03.21.52; Sun, 11 Mar 2018 03:22:07 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932171AbeCKKVA (ORCPT + 99 others); Sun, 11 Mar 2018 06:21:00 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:59192 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932126AbeCKKU7 (ORCPT ); Sun, 11 Mar 2018 06:20:59 -0400 Received: from 79.184.254.228.ipv4.supernova.orange.pl (79.184.254.228) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id 46e60d5508f9a300; Sun, 11 Mar 2018 11:20:57 +0100 From: "Rafael J. Wysocki" To: Doug Smythies Cc: 'Rik van Riel' , 'Mike Galbraith' , 'Thomas Gleixner' , 'Paul McKenney' , 'Thomas Ilsche' , 'Frederic Weisbecker' , 'Linux PM' , 'Aubrey Li' , 'LKML' , 'Peter Zijlstra' Subject: Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework Date: Sun, 11 Mar 2018 11:21:36 +0100 Message-ID: <1773378.CTekz94moy@aspire.rjw.lan> In-Reply-To: <001801d3b90c$99232600$cb697200$@net> References: <2450532.XN8DODrtDf@aspire.rjw.lan> <000701d3b889$eadd5340$c097f9c0$@net> <001801d3b90c$99232600$cb697200$@net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday, March 11, 2018 8:43:02 AM CET Doug Smythies wrote: > On 2018.03.10 15:55 Rafael J. Wysocki wrote: > >On Saturday, March 10, 2018 5:07:36 PM CET Doug Smythies wrote: > >> On 2018.03.10 01:00 Rafael J. Wysocki wrote: > > > ... [snip] ... > > > The information that they often spend more time than a tick > > period in state 0 in one go *is* relevant, though. > > > > > > That issue can be dealt with in a couple of ways and the patch below is a > > rather straightforward attempt to do that. The idea, basically, is to discard > > the result of governor prediction if the tick has been stopped alread and > > the predicted idle duration is within the tick range. > > > > Please try it on top of the v3 and tell me if you see an improvement. > > It seems pretty good so far. > See a new line added to the previous graph, "rjwv3plus". > > http://fast.smythies.com/rjwv3plus_100.png OK, cool! Below is a respin of the last patch which also prevents shallow states from being chosen due to interactivity_req when the tick is stopped. You may also add a poll_idle() fix I've just posted: https://patchwork.kernel.org/patch/10274595/ on top of this. It makes quite a bit of a difference for me. :-) > I'll do another 100% load on one CPU test overnight, this time with > a trace. Thanks!