From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757772AbcBXRCy (ORCPT ); Wed, 24 Feb 2016 12:02:54 -0500 Received: from mga11.intel.com ([192.55.52.93]:28521 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756425AbcBXRCv convert rfc822-to-8bit (ORCPT ); Wed, 24 Feb 2016 12:02:51 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,494,1449561600"; d="scan'208";a="54017012" Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: [PATCH 1/1] intel_pstate: Increase hold-off time before busyness is scaled From: Stephane Gasparini In-Reply-To: <001501d16b33$ff61d200$fe257600$@net> Date: Wed, 24 Feb 2016 17:19:48 +0100 Cc: Mel Gorman , Rafael Wysocki , Ingo Molnar , Peter Zijlstra , Matt Fleming , Mike Galbraith , Linux-PM , LKML , Srinivas Pandruvada Content-Transfer-Encoding: 8BIT Message-Id: <9E20D36B-1323-41AA-969F-3D2DD5021701@linux.intel.com> References: <1455793883-14214-1-git-send-email-mgorman@techsingularity.net> <001501d16b33$ff61d200$fe257600$@net> To: Doug Smythies X-Mailer: Apple Mail (2.3112) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Doug > On Feb 19, 2016, at 5:38 PM, Doug Smythies wrote: > > Hi Steph, > > On 2016.02.19 03:12 Stephane Gasparini wrote: >> >> The issue you are reporting looks like one we improved on android by using >> the average pstate instead of using the last requested pstate >> >> We know that this is improving the ffmpeg encoding performance when using the >> load algorithm. >> >> see patch attached >> >> This patch is only applied on get_target_pstate_use_cpu_load however you can give >> it a try on get_target_pstate_use_performance > > Yes, that type of patch works on the load based approach. > I’m not talking about using average p-state in the scaled_busy computation. I’m talking adding the output of the PID (the number of pstate to ad or subtract) to the average pstate rather than adding this to the current p-sate. The current p-state is in some situation not reflecting the reality as the current p-state can be imposed by a "linked CPU". This is the case when you have a thread migration on "linked CPU" that was not loaded. Its current P-State will be low while its average p-state will reflect the activity of the "linked CPU". I will not claim this is a perfect solution, but this combined to the topology awareness of the scheduler is helping to take better decision. > However, I do not think it works on the performance based approach. Why not? > Well, and if I understand correctly, follow the math and you end up with: > > scaled_busy = 100% > > scaled_busy = (aperf * 100% / mperf) * (max_pstate / * ((aperf * max_pstate) / mperf)) > > ... Doug > > — Steph