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 S1751243AbcCaEFR (ORCPT <rfc822;w@1wt.eu>);
	Thu, 31 Mar 2016 00:05:17 -0400
Received: from mga04.intel.com ([192.55.52.120]:23692 "EHLO mga04.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750734AbcCaEFP (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 31 Mar 2016 00:05:15 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,420,1455004800"; 
   d="scan'208";a="935186719"
Date: Thu, 31 Mar 2016 04:22:18 +0800
From: Yuyang Du <yuyang.du@intel.com>
To: Steve Muckle <steve.muckle@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>,
        "Rafael J. Wysocki" <rafael@kernel.org>, linux-kernel@vger.kernel.org,
        linux-pm@vger.kernel.org, Vincent Guittot <vincent.guittot@linaro.org>,
        Morten Rasmussen <morten.rasmussen@arm.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Juri Lelli <Juri.Lelli@arm.com>,
        Patrick Bellasi <patrick.bellasi@arm.com>,
        Michael Turquette <mturquette@baylibre.com>
Subject: Re: [RFCv7 PATCH 00/10] sched: scheduler-driven CPU frequency
 selection
Message-ID: <20160330202218.GC22689@intel.com>
References: <1456190570-4475-1-git-send-email-smuckle@linaro.org>
 <20160330004506.GB22689@intel.com>
 <56FC7EDB.707@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56FC7EDB.707@linaro.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Steve,

On Wed, Mar 30, 2016 at 06:35:23PM -0700, Steve Muckle wrote:
> This series was dropped in favor of Rafael's schedutil. But on the
> chance that you're still curious about the test setup used to quantify
> the series I'll explain below.
 
I will catch up and learn both.

> These results are meant to show how the governors perform across varying
> workload intensities and periodicities. Higher overhead (OH) numbers
> indicate that the completion times of each period of the workload were
> closer to what they would be when run at fmin (100% overhead would be as
> slow as fmin, 0% overhead would be as fast as fmax). And as described
> above, overruns (OR) indicate that the governor was not responsive
> enough to finish the work in each period of the workload.
> 
> These are just performance metrics so they only tell half the story.
> Power is not factored in at all.
> 
> This provides a quick sanity check that the governor under test (in this
> case, the now defunct schedfreq, or sched for short) performs similarly
> to two of the most commonly used governors, ondemand and interactive, in
> steady state periodic workloads. In the data above sched looks good for
> the most part with the second test case being the biggest exception.
 
Yes, it is indeed a quick sanity check.

Thanks,
Yuyang