From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S965682AbcBCT2A (ORCPT <rfc822;w@1wt.eu>);
	Wed, 3 Feb 2016 14:28:00 -0500
Received: from er-systems.de ([148.251.68.21]:41356 "EHLO er-systems.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S965248AbcBCT17 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Feb 2016 14:27:59 -0500
X-Greylist: delayed 573 seconds by postgrey-1.27 at vger.kernel.org; Wed, 03 Feb 2016 14:27:59 EST
Date: Wed, 3 Feb 2016 20:18:21 +0100 (CET)
From: Thomas Voegtle <thomas@voegtle-clan.de>
X-X-Sender: thomas@er-systems.de
To: "Longepe, Philippe" <philippe.longepe@intel.com>
cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Gasparini, Stephane" <stephane.gasparini@intel.com>,
        "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>
Subject: RE: Performance drop on Baytrail with 4.5-rc2
In-Reply-To: <8B729BF8A98FF048A53185F813A469D935B1A189@HASMSX105.ger.corp.intel.com>
Message-ID: <alpine.LSU.2.11.1602032001430.8870@er-systems.de>
References: <alpine.LSU.2.11.1602012122530.9114@er-systems.de> <8B729BF8A98FF048A53185F813A469D935B19D03@HASMSX105.ger.corp.intel.com>,<alpine.LSU.2.11.1602021854230.30638@er-systems.de>
 <8B729BF8A98FF048A53185F813A469D935B1A189@HASMSX105.ger.corp.intel.com>
User-Agent: Alpine 2.11 (LSU 23 2013-08-11)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Virus-Checker-Version: clamassassin 1.2.4 with clamdscan / ClamAV 0.99/21340/Wed Feb  3 14:36:20 2016 signatures 55.
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 3 Feb 2016, Longepe, Philippe wrote:

> Thank you for sharing this test. I just did a quick test and yes this is 
> really interesting !
>
> Without the scale option, the load is close to 100% for each cpus (so 
> the pstates are increasing up to the turbo frequency) but with 
> scale=320:208, the load is oscillating (close to 50% in average), so the 
> requested frequencies are lower (the power is also reduced).
>
> I have a patch (not yet submitted) that reduce the gap for such a use case.

That's nice, glad the benchmark helped.

> As a temporary solution, you can also switch to performance with:
>
> sudo su
> echo performance > /sys/devices/system/cpu/cpu*/scaling_governor

Yes, ok, thanks.

> However, I still don't know why there is 50% of idle with the scale 
> option (is it using a Hw accelerator ?).


Mh. I don't know. I always thought this is stuff which is not that 
threadable as the mpeg to mp4 conversion, or something like that?


Thanks,

   Thomas