From: liuj97@gmail.com (Jiang Liu)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFT PATCH v1 6/7] amd64: avoid saving and restoring FPSIMD registers until threads access them
Date: Fri, 27 Sep 2013 22:20:10 +0800 [thread overview]
Message-ID: <5245941A.5000805@gmail.com> (raw)
In-Reply-To: <20130927105902.GH9057@mudshark.cambridge.arm.com>
On 09/27/2013 06:59 PM, Will Deacon wrote:
> On Fri, Sep 27, 2013 at 09:04:46AM +0100, Jiang Liu wrote:
>> From: Jiang Liu <jiang.liu@huawei.com>
>>
>> Use PF_USED_MATH flag to mark whether the thread has accessed any FPSIMD
>> registers, so we could avoid saving and restroing FPSIMD registers until
>> threads access them. This may improve performance when lazy FPSIMD restore
>> is disabled.
>
> Hehe, the subject made me smile :)
>
> I suppose that means I have to give a semi-useful review for the patch...
>
>> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
>> Cc: Jiang Liu <liuj97@gmail.com>
>> ---
>> arch/arm64/kernel/fpsimd.c | 38 +++++++++++++++++++++++---------------
>> 1 file changed, 23 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
>> index 267e54a..a81af5f 100644
>> --- a/arch/arm64/kernel/fpsimd.c
>> +++ b/arch/arm64/kernel/fpsimd.c
>> @@ -99,7 +99,8 @@ void fpsimd_disable_lazy_restore(void)
>> * If lazy mode is enabled, caller needs to disable preemption
>> * when calling fpsimd_load_state_lazy() and fpsimd_save_state_lazy().
>> */
>> -static void fpsimd_load_state_lazy(struct fpsimd_state *state)
>> +static void fpsimd_load_state_lazy(struct fpsimd_state *state,
>> + struct task_struct *tsk)
>> {
>> /* Could we reuse the hardware context? */
>> if (state->last_cpu == smp_processor_id() &&
>> @@ -109,13 +110,19 @@ static void fpsimd_load_state_lazy(struct fpsimd_state *state)
>> if (static_key_false(&fpsimd_lazy_mode)) {
>> fpsimd_clear_on_hw(state);
>> fpsimd_enable_trap();
>> - } else {
>> + } else if (tsk_used_math(tsk)) {
>> + fpsimd_disable_trap();
>> fpsimd_load_state(state);
>> + } else {
>> + fpsimd_enable_trap();
>
> One thing worth checking in sequences like this is that you have the
> relevant memory barriers (isb instructions) to ensure that the CPU is
> synchronised wrt side-effects from the msr instructions. *Some* operations
> are self-synchronising, but I don't think this is the case for fpsimd in v8
> (although I haven't re-checked).
>
> Your earlier patch (3/7) doesn't seem to have any of these barriers.
Hi Will,
Thanks for reminder, I tried to confirm this by scanning over
ARMv8 reference manual but failed. So how about changing the code as:
static inline void fpsimd_enable_trap(void)
{
u32 __val;
asm volatile ("mrs %0, cpacr_el1\n"
"tbz %w0, #20, 1f\n"
"and %w0, %w0, #0xFFCFFFFF\n"
"msr cpacr_el1, %0\n"
"isb\n"
"1:"
: "=&r" (__val));
}
static inline void fpsimd_disable_trap(void)
{
u32 __val;
asm volatile ("mrs %0, cpacr_el1\n"
"tbnz %w0, #20, 1f\n"
"orr %w0, %w0, #0x000300000\n"
"msr cpacr_el1, %0\n"
"isb\n"
"1:"
: "=&r" (__val));
}
Thanks!
Gerry
>
> Will
>
WARNING: multiple messages have this Message-ID (diff)
From: Jiang Liu <liuj97@gmail.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
Jiang Liu <jiang.liu@huawei.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFT PATCH v1 6/7] amd64: avoid saving and restoring FPSIMD registers until threads access them
Date: Fri, 27 Sep 2013 22:20:10 +0800 [thread overview]
Message-ID: <5245941A.5000805@gmail.com> (raw)
In-Reply-To: <20130927105902.GH9057@mudshark.cambridge.arm.com>
On 09/27/2013 06:59 PM, Will Deacon wrote:
> On Fri, Sep 27, 2013 at 09:04:46AM +0100, Jiang Liu wrote:
>> From: Jiang Liu <jiang.liu@huawei.com>
>>
>> Use PF_USED_MATH flag to mark whether the thread has accessed any FPSIMD
>> registers, so we could avoid saving and restroing FPSIMD registers until
>> threads access them. This may improve performance when lazy FPSIMD restore
>> is disabled.
>
> Hehe, the subject made me smile :)
>
> I suppose that means I have to give a semi-useful review for the patch...
>
>> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
>> Cc: Jiang Liu <liuj97@gmail.com>
>> ---
>> arch/arm64/kernel/fpsimd.c | 38 +++++++++++++++++++++++---------------
>> 1 file changed, 23 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
>> index 267e54a..a81af5f 100644
>> --- a/arch/arm64/kernel/fpsimd.c
>> +++ b/arch/arm64/kernel/fpsimd.c
>> @@ -99,7 +99,8 @@ void fpsimd_disable_lazy_restore(void)
>> * If lazy mode is enabled, caller needs to disable preemption
>> * when calling fpsimd_load_state_lazy() and fpsimd_save_state_lazy().
>> */
>> -static void fpsimd_load_state_lazy(struct fpsimd_state *state)
>> +static void fpsimd_load_state_lazy(struct fpsimd_state *state,
>> + struct task_struct *tsk)
>> {
>> /* Could we reuse the hardware context? */
>> if (state->last_cpu == smp_processor_id() &&
>> @@ -109,13 +110,19 @@ static void fpsimd_load_state_lazy(struct fpsimd_state *state)
>> if (static_key_false(&fpsimd_lazy_mode)) {
>> fpsimd_clear_on_hw(state);
>> fpsimd_enable_trap();
>> - } else {
>> + } else if (tsk_used_math(tsk)) {
>> + fpsimd_disable_trap();
>> fpsimd_load_state(state);
>> + } else {
>> + fpsimd_enable_trap();
>
> One thing worth checking in sequences like this is that you have the
> relevant memory barriers (isb instructions) to ensure that the CPU is
> synchronised wrt side-effects from the msr instructions. *Some* operations
> are self-synchronising, but I don't think this is the case for fpsimd in v8
> (although I haven't re-checked).
>
> Your earlier patch (3/7) doesn't seem to have any of these barriers.
Hi Will,
Thanks for reminder, I tried to confirm this by scanning over
ARMv8 reference manual but failed. So how about changing the code as:
static inline void fpsimd_enable_trap(void)
{
u32 __val;
asm volatile ("mrs %0, cpacr_el1\n"
"tbz %w0, #20, 1f\n"
"and %w0, %w0, #0xFFCFFFFF\n"
"msr cpacr_el1, %0\n"
"isb\n"
"1:"
: "=&r" (__val));
}
static inline void fpsimd_disable_trap(void)
{
u32 __val;
asm volatile ("mrs %0, cpacr_el1\n"
"tbnz %w0, #20, 1f\n"
"orr %w0, %w0, #0x000300000\n"
"msr cpacr_el1, %0\n"
"isb\n"
"1:"
: "=&r" (__val));
}
Thanks!
Gerry
>
> Will
>
next prev parent reply other threads:[~2013-09-27 14:20 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-27 8:04 [RFT PATCH v1 0/7] enable FPSIMD lazy save and restore for arm64 Jiang Liu
2013-09-27 8:04 ` Jiang Liu
2013-09-27 8:04 ` [RFT PATCH v1 1/7] arm64: fix possible invalid FPSIMD initialization state Jiang Liu
2013-09-27 8:04 ` Jiang Liu
2013-09-27 10:59 ` Catalin Marinas
2013-09-27 10:59 ` Catalin Marinas
2013-09-27 8:04 ` [RFT PATCH v1 2/7] arm64: restore FPSIMD to default state for kernel and signal contexts Jiang Liu
2013-09-27 8:04 ` Jiang Liu
2013-09-27 11:35 ` Catalin Marinas
2013-09-27 11:35 ` Catalin Marinas
2013-09-27 13:20 ` Jiang Liu
2013-09-27 13:20 ` Jiang Liu
2013-09-27 8:04 ` [RFT PATCH v1 3/7] arm64: implement basic lazy save and restore for FPSIMD registers Jiang Liu
2013-09-27 8:04 ` Jiang Liu
2013-09-27 8:04 ` [RFT PATCH v1 4/7] arm64: provide boot option "eagerfpu" to control FPSIMD restore policy Jiang Liu
2013-09-27 8:04 ` Jiang Liu
2013-09-27 8:04 ` [RFT PATCH v1 5/7] arm64: reuse FPSIMD hardware context if possible Jiang Liu
2013-09-27 8:04 ` Jiang Liu
2013-09-27 8:04 ` [RFT PATCH v1 6/7] amd64: avoid saving and restoring FPSIMD registers until threads access them Jiang Liu
2013-09-27 8:04 ` Jiang Liu
2013-09-27 10:59 ` Will Deacon
2013-09-27 10:59 ` Will Deacon
2013-09-27 14:20 ` Jiang Liu [this message]
2013-09-27 14:20 ` Jiang Liu
2013-09-30 9:34 ` Will Deacon
2013-09-30 9:34 ` Will Deacon
2013-09-27 8:04 ` [RFT PATCH v1 7/7] arm64: disable lazy load if FPSIMD registers are frequently used Jiang Liu
2013-09-27 8:04 ` Jiang Liu
2013-09-27 10:50 ` [RFT PATCH v1 0/7] enable FPSIMD lazy save and restore for arm64 Catalin Marinas
2013-09-27 10:50 ` Catalin Marinas
2013-09-27 11:23 ` Will Deacon
2013-09-27 11:23 ` Will Deacon
2013-09-27 15:20 ` Jiang Liu
2013-09-27 15:20 ` Jiang Liu
2013-09-27 16:16 ` Catalin Marinas
2013-09-27 16:16 ` Catalin Marinas
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=5245941A.5000805@gmail.com \
--to=liuj97@gmail.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.