From: Michael Ellerman <mpe@ellerman•id.au>
To: Matt Brown <matthew.brown.dev@gmail•com>, pc@us•ibm.com
Cc: linuxppc-dev@lists•ozlabs.org, Anton Blanchard <anton@samba•org>
Subject: Re: [PATCH] powerpc/lib: Split xor_vmx file to guarantee instruction ordering
Date: Fri, 26 May 2017 14:12:09 +1000 [thread overview]
Message-ID: <87wp948deu.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <CAPoR37YQ-9Q=HacFVrWDg_aS=rPhWhB_SuuevdZDCA2Vu=AVyg@mail.gmail.com>
Matt Brown <matthew.brown.dev@gmail•com> writes:
> On Wed, May 24, 2017 at 11:36 PM, Paul Clarke <pc@us•ibm.com> wrote:
>> On 05/23/2017 06:45 PM, Matt Brown wrote:
>>> The xor_vmx.c file is used for the RAID5 xor operations. In these functions
>>> altivec is enabled to run the operation and then disabled. However due to
>>> compiler instruction reordering, altivec instructions are being run before
>>> enable_altivec() and after disable_altivec().
>>
>> If altivec instructions can be reordered after disable_altivec(), then disable_altivec() is broken, I'd think.
>>
>> Could it be because the isync in mtmsr_isync() is after the mtmsr?
>>
>> disable_kernel_altivec
>> - msr_check_and_clear
>> - __msr_check_and_clear
>> - mtmsr_isync
>
> So it turns out the enable / disable functions don't actually enable
> or disable the use of vector instructions.
> If we have marked the file to be compiled with altivec the compiler
> has free reign to reorder the vector instructions wherever it likes.
> Including reordering it before or after the enable/disable_altivec
> commands.
That's true. Though it's not that the compiler is reordering vector
instructions, it's that it's generating them directly to save/restore
vector arguments.
In enable_kernel_altivec() we have a mtmsr() which is implemented with
inline asm, with a "memory" clobber, so that is effectively a full
compiler barrier. ie. the compiler will not reorder code across that.
> The enable_kernel_altivec and disable_kernel_altivec functions are
> mainly there to empty and restore the vector registers which could
> have been used in user-space. So those functions work as intended,
> although not particularly intuitive.
Yeah, perhaps "allow" would be better. In fact the whole API is a bit
crap and we need to rework it.
cheers
next prev parent reply other threads:[~2017-05-26 4:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 23:45 [PATCH] powerpc/lib: Split xor_vmx file to guarantee instruction ordering Matt Brown
2017-05-24 13:36 ` Paul Clarke
2017-05-25 4:56 ` Matt Brown
2017-05-25 13:25 ` Paul Clarke
2017-05-26 4:12 ` Michael Ellerman [this message]
2017-06-05 10:21 ` Michael Ellerman
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=87wp948deu.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman$(echo .)id.au \
--cc=anton@samba$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=matthew.brown.dev@gmail$(echo .)com \
--cc=pc@us$(echo .)ibm.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