From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] sched: Remove set_task_state()
Date: Tue, 3 Jan 2017 10:04:53 +0000 [thread overview]
Message-ID: <20170103100453.GB5605@leverpostej> (raw)
In-Reply-To: <1483121873-21528-1-git-send-email-dave@stgolabs.net>
On Fri, Dec 30, 2016 at 10:17:53AM -0800, Davidlohr Bueso wrote:
> Secondly for a higher overview, an unlink microbenchmark was used,
> which pounds on a single file with open, close,unlink combos with
> increasing thread counts (up to 4x ncpus). While the workload is
> quite unrealistic, it does contend a lot on the inode mutex or now
> rwsem. With the archs I had access to, the differences are as follows:
>
> == 1. arm64 ==
>
> 0000000000002784 <set_task_state>:
> 2784: f9000c1f str xzr, [x0,#24]
>
> 0000000000002790 <set_current_state>:
> 2790: d5384100 mrs x0, sp_el0
> 2794: f9000c1f str xzr, [x0,#24]
>
> Avg runtime set_task_state(): 2648 msecs
> Avg runtime set_current_state(): 2686 msecs
> Unsurprisingly, the big looser is arm64, due to the masking of sp_el0.
> otoh, x86-64 (known to be fast for get_current()/this_cpu_read_stable()
> caching) and ppc64 (with paca) show similar improvements in the unlink
> microbenches. x86's write latencies delta is similar to the opposite of
> arm64: 50ms vs -40ms, respectively. The small delta for ppc64 (2ms), does
> not represent the gains on the unlink runs. In the case of x86, there was
> a decent amount of variation in the latency runs, but always within a 20
> to 50ms increase), ppc was more constant.
>
> So, do we want to get rid of the interface (and improve performance on
> other archs) at the expense of arm64? Can arm64 do better?
We can defineitely do better; the asm constraints in read_sysreg() are
overly pessimistic for get_current().
Does the below help?
Thanks,
Mark.
---->8----
diff --git a/arch/arm64/include/asm/current.h b/arch/arm64/include/asm/current.h
index f2bcbe2..c9ba5ac 100644
--- a/arch/arm64/include/asm/current.h
+++ b/arch/arm64/include/asm/current.h
@@ -11,7 +11,11 @@
static __always_inline struct task_struct *get_current(void)
{
- return (struct task_struct *)read_sysreg(sp_el0);
+ struct task_struct *tsk;
+
+ asm ("mrs %0, sp_el0" : "=r" (tsk));
+
+ return tsk;
}
#define current get_current()
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: mingo@kernel.org, peterz@infradead.org,
torvalds@linux-foundation.org, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [RFC PATCH] sched: Remove set_task_state()
Date: Tue, 3 Jan 2017 10:04:53 +0000 [thread overview]
Message-ID: <20170103100453.GB5605@leverpostej> (raw)
In-Reply-To: <1483121873-21528-1-git-send-email-dave@stgolabs.net>
On Fri, Dec 30, 2016 at 10:17:53AM -0800, Davidlohr Bueso wrote:
> Secondly for a higher overview, an unlink microbenchmark was used,
> which pounds on a single file with open, close,unlink combos with
> increasing thread counts (up to 4x ncpus). While the workload is
> quite unrealistic, it does contend a lot on the inode mutex or now
> rwsem. With the archs I had access to, the differences are as follows:
>
> == 1. arm64 ==
>
> 0000000000002784 <set_task_state>:
> 2784: f9000c1f str xzr, [x0,#24]
>
> 0000000000002790 <set_current_state>:
> 2790: d5384100 mrs x0, sp_el0
> 2794: f9000c1f str xzr, [x0,#24]
>
> Avg runtime set_task_state(): 2648 msecs
> Avg runtime set_current_state(): 2686 msecs
> Unsurprisingly, the big looser is arm64, due to the masking of sp_el0.
> otoh, x86-64 (known to be fast for get_current()/this_cpu_read_stable()
> caching) and ppc64 (with paca) show similar improvements in the unlink
> microbenches. x86's write latencies delta is similar to the opposite of
> arm64: 50ms vs -40ms, respectively. The small delta for ppc64 (2ms), does
> not represent the gains on the unlink runs. In the case of x86, there was
> a decent amount of variation in the latency runs, but always within a 20
> to 50ms increase), ppc was more constant.
>
> So, do we want to get rid of the interface (and improve performance on
> other archs) at the expense of arm64? Can arm64 do better?
We can defineitely do better; the asm constraints in read_sysreg() are
overly pessimistic for get_current().
Does the below help?
Thanks,
Mark.
---->8----
diff --git a/arch/arm64/include/asm/current.h b/arch/arm64/include/asm/current.h
index f2bcbe2..c9ba5ac 100644
--- a/arch/arm64/include/asm/current.h
+++ b/arch/arm64/include/asm/current.h
@@ -11,7 +11,11 @@
static __always_inline struct task_struct *get_current(void)
{
- return (struct task_struct *)read_sysreg(sp_el0);
+ struct task_struct *tsk;
+
+ asm ("mrs %0, sp_el0" : "=r" (tsk));
+
+ return tsk;
}
#define current get_current()
next prev parent reply other threads:[~2017-01-03 10:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-30 18:17 [RFC PATCH] sched: Remove set_task_state() Davidlohr Bueso
2016-12-30 18:17 ` Davidlohr Bueso
2017-01-03 9:24 ` Peter Zijlstra
2017-01-03 9:24 ` Peter Zijlstra
2017-01-03 10:04 ` Mark Rutland [this message]
2017-01-03 10:04 ` Mark Rutland
2017-01-03 18:06 ` Davidlohr Bueso
2017-01-03 18:06 ` Davidlohr Bueso
2017-01-03 18:13 ` Mark Rutland
2017-01-03 18:13 ` Mark Rutland
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=20170103100453.GB5605@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.