From: Michael Ellerman <mpe@ellerman•id.au>
To: Daniel Axtens <dja@axtens•net>,
Matt Brown <matthew.brown.dev@gmail•com>,
linux-raid@vger•kernel.org
Cc: linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH] raid6/altivec: adding vpermxor implementation for raid6 Q syndrome
Date: Tue, 04 Apr 2017 20:04:44 +1000 [thread overview]
Message-ID: <87pogsv683.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <87wpb1kvy7.fsf@possimpible.ozlabs.ibm.com>
Daniel Axtens <dja@axtens•net> writes:
>> In that function, the flow is:
>> pagefault_disable();
>> enable_kernel_altivec();
>> <vectorised function>
>> pagefault_enable();
>>
>> There are a few things that it would be nice (but by no means essential)
>> to find out:
>> - what is the difference between pagefault and prempt enable/disable
>> - is it required to disable altivec after the end of the function or
>> can we leave that enabled?
>
> Answering my own question here, dc4fbba11e46 ("powerpc: Create
> disable_kernel_{fp,altivec,vsx,spe}()") adds the disable_ function, and
> it's a no-op except under debug conditions. So it should stay.
Yeah enabling altivec for use in the kernel requires saving the
userspace altivec state first (so we don't clobber it).
But once we've enabled it in the kernel, we can just leave it enabled
until we return to userspace and save the cost of disabling it. There's
a small risk that leaving altivec enabled allows some other kernel code
to use altivec when it shouldn't, hence the debug option to make
disable_kernel_altivec() actually disable it.
cheers
next prev parent reply other threads:[~2017-04-04 10:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 5:13 [PATCH] raid6/altivec: adding vpermxor implementation for raid6 Q syndrome Matt Brown
2017-04-03 11:37 ` Daniel Axtens
2017-04-03 21:44 ` Daniel Axtens
2017-04-04 10:04 ` Michael Ellerman [this message]
[not found] ` <CAPoR37YvxSKnerVMPEVE1FzjjT6O6z8sNVsHw_PrWdsVtyEaMA@mail.gmail.com>
[not found] ` <87efx9kkiv.fsf@possimpible.ozlabs.ibm.com>
2017-04-06 5:33 ` Matt Brown
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=87pogsv683.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman$(echo .)id.au \
--cc=dja@axtens$(echo .)net \
--cc=linux-raid@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=matthew.brown.dev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox