Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752189AbcDJDov (ORCPT ); Sat, 9 Apr 2016 23:44:51 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:34268 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751355AbcDJDot (ORCPT ); Sat, 9 Apr 2016 23:44:49 -0400 MIME-Version: 1.0 In-Reply-To: <1460219974.3700.39.camel@gmail.com> References: <1460092854.4051.1.camel@gmail.com> <20160408064510.GK3448@twins.programming.kicks-ass.net> <1460098254.5582.17.camel@gmail.com> <2428384.mEkP3EOpsR@vostro.rjw.lan> <1460184056.3765.160.camel@gmail.com> <1460214622.3714.8.camel@gmail.com> <1460219974.3700.39.camel@gmail.com> Date: Sun, 10 Apr 2016 05:44:47 +0200 X-Google-Sender-Auth: YdM-ipGgtTACD1kr0GWMRyjNcVE Message-ID: Subject: Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732 From: "Rafael J. Wysocki" To: Mike Galbraith Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Peter Zijlstra , "Rafael J. Wysocki" , LKML , Linux PM list , Doug Smythies , Rik van Riel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 990 Lines: 23 On Sat, Apr 9, 2016 at 6:39 PM, Mike Galbraith wrote: > > Hm, setting gov=performance, and taking the average of 3 30 second > interval PkgWatt samples as pipe-test runs.. > > 714KHz/28.03Ws = 25.46 > 877KHz/30.28Ws = 28.96 > > ..for pipe-test, the tradeoff look a bit more like red than green. Well, fair enough, but that's just pipe-test, and what about the people who don't see the performance gain and see the energy loss, like Doug? Essentially, this trades performance gains in somewhat special workloads for increased energy consumption in idle. Those workloads need not be run by everybody, but idle is. That said I applied the patch you're complaining about mostly because the commit that introduced the change in question in 4.5 claimed that it wouldn't affect idle power on systems with reasonably fast C1, but that didn't pass the reality test. I'm not totally against restoring that change, but it would need to be based on very solid evidence.