Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1784321imm; Wed, 16 May 2018 03:04:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpH+4qP3rhT2TUTmH9QtlFpmioEUxZUvNpz4nZ4vH7ARieYlMHcfzJZT7LXExbpHFZKz4ke X-Received: by 2002:a17:902:680e:: with SMTP id h14-v6mr255325plk.90.1526465073824; Wed, 16 May 2018 03:04:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526465073; cv=none; d=google.com; s=arc-20160816; b=dzY1zvCWDpYzyXi+r9Laexs0u9I459bPX93WPYEFlGN8M0JUJlQUowNIoXbTmLCOx4 7/uvCd3JIpi5BqnqcAGH1FwBAt6wTMq0kKvyE/6of6wRytCGtQqcXy4pKmrL6pLy9gs8 jX5m0fLdlFYNhotWeGA3LnNgSNTEUw9JgxwL+XdN5YQHoy9IsCthcW0gYlD9HuL8HQkE 7OV/xVj2KJ1mUD8kgjKtn1YdWj+EVYyrLUIgm2cnUWHZ5F9b0ObrfSenACkwkkFKL2Gc ncAFYOnVcVsa0SKKfgxRvoHLqQRdu8jXhUSAvbheeyHetrm2WdJLZOw9HT5cehxqG9+2 wp/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=unwZcWHWwNRw1M5bgYkr7WebESOSvHsUK/KXiMxE6nE=; b=GQZqdFlRDj+iOwlv9KNy0faWRyYBtsJkVMZRjZ1TFbCFYmXlpzeKFr1K1sZTakXSkz nlpAMV6gDZxFYbFUqNzxfBPIHGI/ahhzTfr2twk2PMWbq7ECZrFW7YfPMHiODNUqSW3g /bpWKZpZjKPEQ2MDVetcMsIXmUayBFQZvJfMjSZaK45wtmRAp8LHo2KHnb/v076rT/71 dn1xMuQ7Ni+0336N6qD7rBNyK1t31VlX+qojfjSqgr2pcZGGOAN0CzSpkFIFkAPik7B1 w9XCE4uDrfZd2wmcwqYrBpGw2UqnEDuoapeg7eKLLwzaLry/jG2T0i2IICFaL2IX17oV tJJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=g/Nzz1v3; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m32-v6si2203826pld.438.2018.05.16.03.04.19; Wed, 16 May 2018 03:04:33 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=g/Nzz1v3; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753081AbeEPKCq (ORCPT + 99 others); Wed, 16 May 2018 06:02:46 -0400 Received: from mail-ot0-f196.google.com ([74.125.82.196]:37452 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752958AbeEPJpe (ORCPT ); Wed, 16 May 2018 05:45:34 -0400 Received: by mail-ot0-f196.google.com with SMTP id 77-v6so153072otd.4; Wed, 16 May 2018 02:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=unwZcWHWwNRw1M5bgYkr7WebESOSvHsUK/KXiMxE6nE=; b=g/Nzz1v3xYTfZyIyaVHzqXFESptRfrLnGhnHrSaXKXNITYKng8lL1xvfK0ASqIiUe4 BlBhWQa9rGc6a+bDNEr23/HFCb/WShKotzKTTU6HoWnZB5VRNhh7VRo/58UoRpATL5QL /079qUSq16nUv1uEchPR3waGcCTIfuiDei026fdsi9v+s1PrRgz+oSpmLFsyJNt0l1PZ wM489rUJqidB+YArWb3pRoXXFzN1/9KmqlpCUJWFrJnOqoNl9mFboUnfjIVoGg300MiO uevBjXSBaeE3hEHPmo8KY8gOrQoRirfsIn/XrirTLv/QMuSXiJWm4tvsBYdgzKnUfdRp LKPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=unwZcWHWwNRw1M5bgYkr7WebESOSvHsUK/KXiMxE6nE=; b=pZeVy9fW6I29zUT7a2UPIVv+eRe8D36kB/USj+o/w44Qxc4XrJmacr1yCNkqURgOZV DXoiIW/iZ7uySU5Sy+OHrOHRHRdvCvaUDOsVCQFhIQ150q5zFarcA5r9GFqrJVwjisay u/lJxftmwacEzvyYIHwn1rwOAj+fdE8gI01wVqGEug5sQFL21bLxYQMc335UMzTMhLG6 ceQt9GSiGX5gooSSc5YuR4t56O0bX/W4lsNu9TWo/H/KXP/oCno1u0CwJREkkxXQV37y DwsTHmIZ/eNdzL4+D5VbAyh4TV6cbpMhdv5wPOqmfgrhQ2Vrhnhoz8nxOvSo8PreBJcf Qcmw== X-Gm-Message-State: ALKqPwfmdyb7JDKmLo93F2jDh1qxDqvhuX602flYFTuJO92HhxiqSyUH 1A/Ml9aArGcC4XAh0RYPNzk9qWRkrSiXNFuLWoU= X-Received: by 2002:a9d:721d:: with SMTP id u29-v6mr93033otj.305.1526463933358; Wed, 16 May 2018 02:45:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1468:0:0:0:0:0 with HTTP; Wed, 16 May 2018 02:45:32 -0700 (PDT) In-Reply-To: <20180516044911.28797-6-srinivas.pandruvada@linux.intel.com> References: <20180516044911.28797-1-srinivas.pandruvada@linux.intel.com> <20180516044911.28797-6-srinivas.pandruvada@linux.intel.com> From: "Rafael J. Wysocki" Date: Wed, 16 May 2018 11:45:32 +0200 X-Google-Sender-Auth: 17Zu8diYqfOtwGFeuPe-WYSmyVk Message-ID: Subject: Re: [RFC/RFT] [PATCH 05/10] cpufreq: intel_pstate: HWP boost performance on IO Wake To: Srinivas Pandruvada Cc: Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Borislav Petkov , Len Brown , "Rafael J. Wysocki" , Mel Gorman , "the arch/x86 maintainers" , Linux PM , Viresh Kumar , Juri Lelli , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 16, 2018 at 6:49 AM, Srinivas Pandruvada wrote: > When a task is woken up from IO wait, boost HWP prformance to max. This > helps IO workloads on servers with per core P-states. But changing limits > has extra over head of issuing new HWP Request MSR, which takes 1000+ > cycles. So this change limits setting HWP Request MSR. Also request can > be for a remote CPU. > Rate control in setting HWP Requests: > - If the current performance is around P1, simply ignore IO flag. > - Once set wait till hold time, till remove boost. While the boost > is on, another IO flags is notified, it will prolong boost. > - If the IO flags are notified multiple ticks apart, this may not be > IO bound task. Othewise idle system gets periodic boosts for one > IO wake. > > Signed-off-by: Srinivas Pandruvada > --- > drivers/cpufreq/intel_pstate.c | 75 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 75 insertions(+) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index e200887..d418265 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -224,6 +225,8 @@ struct global_params { > * @hwp_req_cached: Cached value of the last HWP request MSR > * @csd: A structure used to issue SMP async call, which > * defines callback and arguments > + * @hwp_boost_active: HWP performance is boosted on this CPU > + * @last_io_update: Last time when IO wake flag was set > * > * This structure stores per CPU instance data for all CPUs. > */ > @@ -258,6 +261,8 @@ struct cpudata { > s16 epp_saved; > u64 hwp_req_cached; > call_single_data_t csd; > + bool hwp_boost_active; > + u64 last_io_update; > }; > > static struct cpudata **all_cpu_data; > @@ -1421,10 +1426,80 @@ static void csd_init(struct cpudata *cpu) > cpu->csd.info = cpu; > } > > +/* > + * Long hold time will keep high perf limits for long time, > + * which negatively impacts perf/watt for some workloads, > + * like specpower. 3ms is based on experiements on some > + * workoads. > + */ > +static int hwp_boost_hold_time_ms = 3; > + > +/* Default: This will roughly around P1 on SKX */ > +#define BOOST_PSTATE_THRESHOLD (SCHED_CAPACITY_SCALE / 2) > +static int hwp_boost_pstate_threshold = BOOST_PSTATE_THRESHOLD; > + > +static inline bool intel_pstate_check_boost_threhold(struct cpudata *cpu) > +{ > + /* > + * If the last performance is above threshold, then return false, > + * so that caller can ignore boosting. > + */ > + if (arch_scale_freq_capacity(cpu->cpu) > hwp_boost_pstate_threshold) > + return false; > + > + return true; > +} > + > static inline void intel_pstate_update_util_hwp(struct update_util_data *data, > u64 time, unsigned int flags) > { > + struct cpudata *cpu = container_of(data, struct cpudata, update_util); > + > + if (flags & SCHED_CPUFREQ_IOWAIT) { > + /* > + * Set iowait_boost flag and update time. Since IO WAIT flag > + * is set all the time, we can't just conclude that there is > + * some IO bound activity is scheduled on this CPU with just > + * one occurrence. If we receive at least two in two > + * consecutive ticks, then we start treating as IO. So > + * there will be one tick latency. > + */ > + if (time_before64(time, cpu->last_io_update + 2 * TICK_NSEC) && > + intel_pstate_check_boost_threhold(cpu)) > + cpu->iowait_boost = true; > + > + cpu->last_io_update = time; > + cpu->last_update = time; This is a shared data structure and it gets updated without synchronization, unless I'm missing something. How much does the cross-CPU case matter? > + } > > + /* > + * If the boost is active, we will remove it after timeout on local > + * CPU only. > + */ > + if (cpu->hwp_boost_active) { > + if (smp_processor_id() == cpu->cpu) { > + bool expired; > + > + expired = time_after64(time, cpu->last_update + > + (hwp_boost_hold_time_ms * NSEC_PER_MSEC)); > + if (expired) { > + intel_pstate_hwp_boost_down(cpu); > + cpu->hwp_boost_active = false; > + cpu->iowait_boost = false; > + } > + } > + return; > + } > + > + cpu->last_update = time; > + > + if (cpu->iowait_boost) { > + cpu->hwp_boost_active = true; > + if (smp_processor_id() == cpu->cpu) > + intel_pstate_hwp_boost_up(cpu); > + else > + smp_call_function_single_async(cpu->cpu, &cpu->csd); > + } > } > > static inline void intel_pstate_calc_avg_perf(struct cpudata *cpu) > -- > 2.9.5 >