Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751243AbcCaEFR (ORCPT ); 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 ); 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 To: Steve Muckle Cc: Peter Zijlstra , Ingo Molnar , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Michael Turquette 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: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1317 Lines: 30 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