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.id.au \
--cc=dja@axtens.net \
--cc=linux-raid@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=matthew.brown.dev@gmail.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.