Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp478416imm; Fri, 1 Jun 2018 04:31:29 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJofs0DQEhogEhI8bXpLB0tZccGhIVF7JON9bEIYwxnLFwrd7QGo4FUDdrVjeLTNUpaVw2i X-Received: by 2002:a65:46cb:: with SMTP id n11-v6mr8397627pgr.193.1527852689433; Fri, 01 Jun 2018 04:31:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527852689; cv=none; d=google.com; s=arc-20160816; b=T/GYm7V7wNlFkSh7a5DMDmLteDLQSTe9Lrn/3aFhvbeAmiMqxpkRdjxmyDekH57v+e KB2Y7W8+8yAinDHK/wdC/SnruxQdgAIqXJewka7uCLJ0c2UWVvz6hzGKDoxQuhLmW4L6 gD1AwMIFAtPHDLiMVbXskKnBHeUCH+K7vLxN6K0RG99Vsz1JURK7A04p6HNKcZwsxpPE zdZZtEy/6R4HxfYdb1xGrpHQvI7Ap079wwHPJrf1A+aQpafrQHGKR2wqyeiUF71pjt43 PrCI4i18hfgK07PsDI+/5RnyPQFZDVO9AHKD6U0/0kbtdxBmt+ib69QXLLoLKkaJeGy1 rJAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=RFwr/EEOOFRzu9/wtajJhVZxb/Zq5GEZv8Vjs2Y/GXY=; b=wapSvQj9FN0hD7dVavAMbvP/M45toJ0G9byjGwl1gSuQxcoeE9iHj/bATEAirxQ0Dt qQ1Qk8aU7uGm4Od7Pt6Td+nu/q/egVn+zl1o0L8f3LLhP5Om0+EE+2mDtkEnS+ye3wuz yjErrJDeBsSohDIeFy+UHLymzvfrdmlR8Op37v6VTA2N/echOZacByjadTQ/1iPgL0+f sdvnl8cy75zrT3I0uF8raHPZR3VumLz6P8bTEP0Oy539uwn+n+x05L0SzO+rShz5w47g fRuH1lkc+0EMI5XW3Qknr09BdLFBJyu8RXm86rzkmCOt40B2k54rCHeZa4AYt06Z0kQC 9ufQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 5-v6si39301685pfd.73.2018.06.01.04.31.15; Fri, 01 Jun 2018 04:31:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752199AbeFAL2z (ORCPT + 99 others); Fri, 1 Jun 2018 07:28:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:54720 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751835AbeFAL2w (ORCPT ); Fri, 1 Jun 2018 07:28:52 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 21634AC81; Fri, 1 Jun 2018 11:28:51 +0000 (UTC) Date: Fri, 1 Jun 2018 13:32:09 +0200 From: Giovanni Gherdovich To: Srinivas Pandruvada Cc: lenb@kernel.org, rjw@rjwysocki.net, peterz@infradead.org, mgorman@techsingularity.net, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, juri.lelli@redhat.com, viresh.kumar@linaro.org Subject: Re: [RFC/RFT] [PATCH v3 0/4] Intel_pstate: HWP Dynamic performance boost Message-ID: <20180601113209.rp35aukgstkqbxtc@linux-h043> References: <20180531225143.34270-1-srinivas.pandruvada@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180531225143.34270-1-srinivas.pandruvada@linux.intel.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 31, 2018 at 03:51:39PM -0700, Srinivas Pandruvada wrote: > v3 > - Removed atomic bit operation as suggested. > - Added description of contention with user space. > - Removed hwp cache, boost utililty function patch and merged with util callback > patch. This way any value set is used somewhere. > > Waiting for test results from Mel Gorman, who is the original reporter. > Hello Srinivas, thanks for this series. I'm testing it on behalf of Mel; while I'm waiting for more benchmarks to finish, an initial report I've got from dbench on ext4 looks very promising. Good! Later when I have it all I'll post my detailed results. Giovanni Gherdovich SUSE Labs > v2 > This is a much simpler version than the previous one and only consider IO > boost, using the existing mechanism. There is no change in this series > beyond intel_pstate driver. > > Once PeterZ finishes his work on frequency invariant, I will revisit > thread migration optimization in HWP mode. > > Other changes: > - Gradual boost instead of single step as suggested by PeterZ. > - Cross CPU synchronization concerns identified by Rafael. > - Split the patch for HWP MSR value caching as suggested by PeterZ. > > Not changed as suggested: > There is no architecture way to identify platform with Per-core > P-states, so still have to enable feature based on CPU model. > > ----------- > v1 > > This series tries to address some concern in performance particularly with IO > workloads (Reported by Mel Gorman), when HWP is using intel_pstate powersave > policy. > > Background > HWP performance can be controlled by user space using sysfs interface for > max/min frequency limits and energy performance preference settings. Based on > workload characteristics these can be adjusted from user space. These limits > are not changed dynamically by kernel based on workload. > > By default HWP defaults to energy performance preference value of 0x80 on > majority of platforms(Scale is 0-255, 0 is max performance and 255 is min). > This value offers best performance/watt and for majority of server workloads > performance doesn't suffer. Also users always have option to use performance > policy of intel_pstate, to get best performance. But user tend to run with > out of box configuration, which is powersave policy on most of the distros. > > In some case it is possible to dynamically adjust performance, for example, > when a CPU is woken up due to IO completion or thread migrate to a new CPU. In > this case HWP algorithm will take some time to build utilization and ramp up > P-states. So this may results in lower performance for some IO workloads and > workloads which tend to migrate. The idea of this patch series is to > temporarily boost performance dynamically in these cases. This is only > applicable only when user is using powersave policy, not in performance policy. > > Results on a Skylake server: > > Benchmark Improvement % > ---------------------------------------------------------------------- > dbench 50.36 > thread IO bench (tiobench) 10.35 > File IO 9.81 > sqlite 15.76 > X264 -104 cores 9.75 > > Spec Power (Negligible impact 7382 Vs. 7378) > Idle Power No change observed > ----------------------------------------------------------------------- > > HWP brings in best performace/watt at EPP=0x80. Since we are boosting > EPP here to 0, the performance/watt drops upto 10%. So there is a power > penalty of these changes. > > Also Mel Gorman provided test results on a prior patchset, which shows > benifits of this series. > > Srinivas Pandruvada (4): > cpufreq: intel_pstate: Add HWP boost utility and sched util hooks > cpufreq: intel_pstate: HWP boost performance on IO wakeup > cpufreq: intel_pstate: New sysfs entry to control HWP boost > cpufreq: intel_pstate: enable boost for SKX > > drivers/cpufreq/intel_pstate.c | 177 ++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 173 insertions(+), 4 deletions(-) > > -- > 2.13.6 > >