From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Mel Gorman <mgorman@techsingularity.net>,
Mike Galbraith <efault@gmx.de>,
Matt Fleming <matt@codeblueprint.co.uk>,
LKML <linux-kernel@vger.kernel.org>,
srinivas.pandruvada@linux.intel.com
Subject: Re: [PATCH 4/4] sched/fair: Use a recently used CPU as an idle candidate and the basis for SIS
Date: Fri, 2 Feb 2018 13:46:47 +0100 [thread overview]
Message-ID: <20180202124647.GK2269@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <8930678.7E2iWGoJnn@aspire.rjw.lan>
On Fri, Feb 02, 2018 at 12:42:29PM +0100, Rafael J. Wysocki wrote:
> > If you really care you can do async IPIs and do a custom serialization
> > that only waits when you do back-to-back things, which should be fairly
> > uncommon I'd think.
>
> In this particular case we don't want to return to user space before the
> MSR is actually written with the new value.
Why not?
I was thinking of something like the below, which would in fact do
exactly that.
---
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 7edf7a0e5a96..f0caa5cc7adb 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -29,6 +29,7 @@
#include <linux/debugfs.h>
#include <linux/acpi.h>
#include <linux/vmalloc.h>
+#include <linux/smp.h>
#include <trace/events/power.h>
#include <asm/div64.h>
@@ -767,6 +768,40 @@ static void intel_pstate_hwp_set(unsigned int cpu)
wrmsrl_on_cpu(cpu, MSR_HWP_REQUEST, value);
}
+static void __intel_pstate_hwp_set_desired(int val)
+{
+ u64 value;
+
+ value = rdmsrl(MSR_HWP_REQUEST);
+ value &= ~GENMASK_ULL(23, 16);
+ value |= (val & 0xff) << 16;
+ wrmsrl(MSR_HWP_REQUEST, val);
+}
+
+static void __intel_pstate_hwp_func(void *data)
+{
+ __intel_pstate_hwp_set_desired((int)data);
+}
+
+static DEFINE_PER_CPU_SHARED_ALIGNED(struct __call_single_data, csd_data);
+
+static void intel_pstate_hwp_set_desired(int cpu, int val)
+{
+ struct call_function_data *csd;
+
+ preempt_disable();
+ csd = this_cpu_ptr(&csd_data);
+ /* wait for previous invocation to complete */
+ csd_lock_wait(csd);
+
+ csd->func = __intel_pstate_hwp_func;
+ csd->info = (unsigned long)val;
+
+ smp_call_function_single_async(cpu, csd);
+ preempt_enable();
+}
+
+
static int intel_pstate_hwp_save_state(struct cpufreq_policy *policy)
{
struct cpudata *cpu_data = all_cpu_data[policy->cpu];
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 9fb239e12b82..2bc125ec6146 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -14,6 +14,11 @@
#include <linux/init.h>
#include <linux/llist.h>
+enum {
+ CSD_FLAG_LOCK = 0x01,
+ CSD_FLAG_SYNCHRONOUS = 0x02,
+};
+
typedef void (*smp_call_func_t)(void *info);
struct __call_single_data {
struct llist_node llist;
@@ -26,6 +31,11 @@ struct __call_single_data {
typedef struct __call_single_data call_single_data_t
__aligned(sizeof(struct __call_single_data));
+static __always_inline void csd_lock_wait(call_single_data_t *csd)
+{
+ smp_cond_load_acquire(&csd->flags, !(VAL & CSD_FLAG_LOCK));
+}
+
/* total number of cpus in this system (may exceed NR_CPUS) */
extern unsigned int total_cpus;
diff --git a/kernel/smp.c b/kernel/smp.c
index 084c8b3a2681..af0ef9eb7679 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -22,11 +22,6 @@
#include "smpboot.h"
-enum {
- CSD_FLAG_LOCK = 0x01,
- CSD_FLAG_SYNCHRONOUS = 0x02,
-};
-
struct call_function_data {
call_single_data_t __percpu *csd;
cpumask_var_t cpumask;
@@ -103,11 +98,6 @@ void __init call_function_init(void)
* previous function call. For multi-cpu calls its even more interesting
* as we'll have to ensure no other cpu is observing our csd.
*/
-static __always_inline void csd_lock_wait(call_single_data_t *csd)
-{
- smp_cond_load_acquire(&csd->flags, !(VAL & CSD_FLAG_LOCK));
-}
-
static __always_inline void csd_lock(call_single_data_t *csd)
{
csd_lock_wait(csd);
next prev parent reply other threads:[~2018-02-02 12:47 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 10:45 [PATCH 0/4] Reduce migrations and unnecessary spreading of load to multiple CPUs Mel Gorman
2018-01-30 10:45 ` [PATCH 1/4] sched/fair: Remove unnecessary parameters from wake_affine_idle Mel Gorman
2018-02-06 11:55 ` [tip:sched/urgent] sched/fair: Remove unnecessary parameters from wake_affine_idle() tip-bot for Mel Gorman
2018-01-30 10:45 ` [PATCH 2/4] sched/fair: Restructure wake_affine to return a CPU id Mel Gorman
2018-02-06 11:56 ` [tip:sched/urgent] sched/fair: Restructure wake_affine*() " tip-bot for Mel Gorman
2018-01-30 10:45 ` [PATCH 3/4] sched/fair: Do not migrate if the prev_cpu is idle Mel Gorman
2018-02-06 11:56 ` [tip:sched/urgent] " tip-bot for Mel Gorman
2018-01-30 10:45 ` [PATCH 4/4] sched/fair: Use a recently used CPU as an idle candidate and the basis for SIS Mel Gorman
2018-01-30 11:50 ` Peter Zijlstra
2018-01-30 12:57 ` Mel Gorman
2018-01-30 13:15 ` Peter Zijlstra
2018-01-30 13:25 ` Mel Gorman
2018-01-30 13:40 ` Peter Zijlstra
2018-01-30 14:06 ` Mel Gorman
2018-01-31 9:22 ` Rafael J. Wysocki
2018-01-31 10:17 ` Peter Zijlstra
2018-01-31 11:54 ` Mel Gorman
2018-01-31 17:44 ` Srinivas Pandruvada
2018-02-01 9:11 ` Peter Zijlstra
2018-02-01 7:50 ` Rafael J. Wysocki
2018-02-01 9:11 ` Peter Zijlstra
2018-02-01 13:18 ` Srinivas Pandruvada
2018-02-02 11:00 ` Rafael J. Wysocki
2018-02-02 14:54 ` Srinivas Pandruvada
2018-02-02 19:48 ` Mel Gorman
2018-02-02 20:01 ` Srinivas Pandruvada
2018-02-05 11:10 ` Mel Gorman
2018-02-05 17:04 ` Srinivas Pandruvada
2018-02-05 17:50 ` Mel Gorman
2018-02-04 8:42 ` Rafael J. Wysocki
2018-02-04 8:38 ` Rafael J. Wysocki
2018-02-02 11:42 ` Rafael J. Wysocki
2018-02-02 12:46 ` Peter Zijlstra [this message]
2018-02-02 12:55 ` Peter Zijlstra
2018-02-02 14:08 ` Peter Zijlstra
2018-02-03 16:30 ` Srinivas Pandruvada
2018-02-05 10:44 ` Peter Zijlstra
2018-02-05 10:58 ` Ingo Molnar
2018-02-02 12:58 ` Peter Zijlstra
2018-02-02 13:27 ` Mel Gorman
2018-01-30 13:15 ` Mike Galbraith
2018-01-30 13:25 ` Peter Zijlstra
2018-01-30 13:35 ` Mike Galbraith
2018-01-30 11:53 ` Peter Zijlstra
2018-01-30 12:59 ` Mel Gorman
2018-01-30 13:06 ` Peter Zijlstra
2018-01-30 13:18 ` Mel Gorman
2018-02-06 11:56 ` [tip:sched/urgent] " tip-bot for Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180202124647.GK2269@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mgorman@techsingularity.net \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.