Received: by 10.223.185.116 with SMTP id b49csp6323334wrg; Thu, 8 Mar 2018 05:41:59 -0800 (PST) X-Google-Smtp-Source: AG47ELv6NbkcbfwpBjNSyptSeLXrmm2JOLudue8XUoAbhMSqAIAOMaJ9DVDGXLQeKDkhXV3NEeio X-Received: by 2002:a17:902:aa8e:: with SMTP id d14-v6mr17108036plr.318.1520516519811; Thu, 08 Mar 2018 05:41:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520516519; cv=none; d=google.com; s=arc-20160816; b=sv6ZP0TwLD+Rck37sRHk6K0BMaV9aBrfRe7nOJ4GAc1v4RjA11M+Rxc+cvJu7Jy7ru ntdCf/eDokGRPyN+Z9YodzSxSb/CQoKCRHWbCVMVuY70MeLIWr6X/bTKYCfaQWVSzOg2 1fY43Fw9sYWILrrY9EWYw925mBG1+mX6lrKxZ1ph4qOtmaOkm41EXUsUnxaAFsYCHLMM +756nNLXia/unISY9hjT37tuTsgDg5nb0hvR3L7LXYNqFC5dzQsPxO1fQJI6+MXrrig5 VOWQ4z4D5do7w3OXWCfGmkg9nW0+QwAiyHOAzfI0fG8H4hnvh4gTMoX/CcP5HbH4Hq5I 6XBw== 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:date:cc:to:from:subject:message-id :arc-authentication-results; bh=oVmN7MdSCwCr7l1Pm+zn6A81lX3Jlkaq8lpilY84tfg=; b=BElGbq5+/Gn8m5nF4OWDOAjcqsdNUz1bjH5q8O7Whqz2vuYvgP2LePR6UdyJpObsRp OdzBLMR8TKywuDkcA9opSR5V0aPXC4JHKGkXxAWPHLQq0nGDhUk5wSO816isaUh77TuU pjSmkaqR+mWVscX/OajMgWHyx90aMgF9hQAOShdpD87FHP1l8HRiBe9HvQDeg8gOmapS RNQvQmOpqthYyKSabzPFGwSJ3/7cZtZrjo5sbbcePted8nM7DxA2ifbglygdWJ9uRdbs 11mjFLRDvyVLWO5iUm7zCbAzBIvW38nqlb6qxXkG3C1iyfonWgnS9n7WoxfcGd0h4fV2 dg5Q== 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 x6si949914pfx.81.2018.03.08.05.41.45; Thu, 08 Mar 2018 05:41:59 -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; 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 S966268AbeCHNkY (ORCPT + 99 others); Thu, 8 Mar 2018 08:40:24 -0500 Received: from mx2.suse.de ([195.135.220.15]:50525 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934137AbeCHNkX (ORCPT ); Thu, 8 Mar 2018 08:40:23 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 80F93AB9F; Thu, 8 Mar 2018 13:40:19 +0000 (UTC) Message-ID: <1520516417.7807.88.camel@suse.de> Subject: Re: [RFC/RFT][PATCH v2 0/6] sched/cpuidle: Idle loop rework From: Mike Galbraith To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Peter Zijlstra , Linux PM , Thomas Gleixner , Frederic Weisbecker , Paul McKenney , Thomas Ilsche , Doug Smythies , Rik van Riel , Aubrey Li , LKML Date: Thu, 08 Mar 2018 14:40:17 +0100 In-Reply-To: References: <2067762.1uWBf5RSRc@aspire.rjw.lan> <1520505099.7807.60.camel@suse.de> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-03-08 at 12:10 +0100, Rafael J. Wysocki wrote: > On Thu, Mar 8, 2018 at 11:31 AM, Mike Galbraith wrote: > 1 2 3 > > 4.16.0.g1b88acc-master 6.95 7.03 6.91 (virgin) > > 4.16.0.g1b88acc-master 7.20 7.25 7.26 (+v2) > > 4.16.0.g1b88acc-master 6.90 7.06 6.95 (+local) > > > > Why would v2 charge the light firefox load a small but consistent fee? > > Two effects may come into play here I think. > > One is that allowing the tick to run biases the menu governor's > predictions towards the lower end, so we may use shallow states more > as a result then (Peter was talking about that). Hm, I'd expect that to show up in +local as well then, as it keeps the tick running when avg_idle < sched_migration_cost (convenient magic number), but the firefox load runs at the same wattage as virgin. ?I'm also doing this... --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -335,7 +335,7 @@ static int menu_select(struct cpuidle_dr * C1's exit latency exceeds the user configured limit. */ polling_threshold = max_t(unsigned int, 20, s->target_residency); - if (data->next_timer_us > polling_threshold && + if (expected_interval > polling_threshold && latency_req > s->exit_latency && !s->disabled && !dev->states_usage[1].disable) first_idx = 1; ...to help out high frequency cross core throughput, but the firefox load apparently doesn't tickle that, as significant polling would surely show in the wattage. -Mike