On 11/29/2012 01:18 PM, Andi Kleen wrote:
>
>> Either way, this implementatin technique was used for the MMX/SSE
>> implementations without any problems for 9 years now.
>
> It's still wrong.
>
> Lying to the compiler usually bites you at some point.
>
It's not lying to the compiler. It is te
On 11/29/2012 01:18 PM, Andi Kleen wrote:
>
> Can you quote it from the manual? As I understand volatile as usual
> is not clearly defined.
>
> gcc has a lot of optimization passes and volatile bugs are common.
>
I talked it over with H.J. and we walked through the code. The
documentation is
> The code is compiled so that the xmm/ymm registers are not available to
> the compiler. Do you have any known examples of asm volatiles being
> reordered *with respect to each other*? My understandings of gcc is
> that volatile operations are ordered with respect to each other (not
> necessaril
On 11/29/2012 12:09 PM, Andi Kleen wrote:
> Jim Kukunas writes:
>> +
>> +/* ymm0 = x0f[16] */
>> +asm volatile("vpbroadcastb %0, %%ymm7" : : "m" (x0f));
>> +
>> +while (bytes) {
>> +#ifdef CONFIG_X86_64
>> +asm volatile("vmovdqa %0, %%ymm1" : : "m" (q[0]));
>> +
Jim Kukunas writes:
> +
> + /* ymm0 = x0f[16] */
> + asm volatile("vpbroadcastb %0, %%ymm7" : : "m" (x0f));
> +
> + while (bytes) {
> +#ifdef CONFIG_X86_64
> + asm volatile("vmovdqa %0, %%ymm1" : : "m" (q[0]));
> + asm volatile("vmovdqa %0, %%ymm9" : : "m" (q[32
On Fri, 9 Nov 2012 11:56:10 -0800 Jim Kukunas
wrote:
> On Fri, Nov 09, 2012 at 10:50:25PM +1100, Neil Brown wrote:
> > On Fri, 09 Nov 2012 12:39:05 +0100 "H. Peter Anvin" wrote:
> >
> > > Sorry, we cannot share those at this time since the hardwarenis not yet
> > > released.
> >
> > Can I tak
On Fri, Nov 09, 2012 at 10:50:25PM +1100, Neil Brown wrote:
> On Fri, 09 Nov 2012 12:39:05 +0100 "H. Peter Anvin" wrote:
>
> > Sorry, we cannot share those at this time since the hardwarenis not yet
> > released.
>
> Can I take that to imply "Acked-by: "H. Peter Anvin" " ??
>
> It would be nic
Yes, consider it an implicit Acked-by.
NeilBrown wrote:
>On Fri, 09 Nov 2012 12:39:05 +0100 "H. Peter Anvin"
>wrote:
>
>> Sorry, we cannot share those at this time since the hardwarenis not
>yet released.
>
>Can I take that to imply "Acked-by: "H. Peter Anvin" "
>??
>
>It would be nice to have
On Fri, 09 Nov 2012 12:39:05 +0100 "H. Peter Anvin" wrote:
> Sorry, we cannot share those at this time since the hardwarenis not yet
> released.
Can I take that to imply "Acked-by: "H. Peter Anvin" " ??
It would be nice to have at least a statement like:
These patches have been tested both wi
Am Freitag, den 09.11.2012, 12:39 +0100 schrieb H. Peter Anvin:
> Sorry, we cannot share those at this time since the hardwarenis not yet
> released.
Too bad. Then I suggest an additional run time switch to enable and
disable that code path. So people later can easily test themselves.
Thanks,
Sorry, we cannot share those at this time since the hardwarenis not yet
released.
Paul Menzel wrote:
>Dear Jim,
>
>
>Am Donnerstag, den 08.11.2012, 13:47 -0800 schrieb Jim Kukunas:
>> Optimize RAID6 recovery functions to take advantage of
>> the 256-bit YMM integer instructions introduced in AV
Dear Jim,
Am Donnerstag, den 08.11.2012, 13:47 -0800 schrieb Jim Kukunas:
> Optimize RAID6 recovery functions to take advantage of
> the 256-bit YMM integer instructions introduced in AVX2.
in my experiencing optimizations always have to be back up by
benchmarks. Could you add those to the commi
Optimize RAID6 recovery functions to take advantage of
the 256-bit YMM integer instructions introduced in AVX2.
Signed-off-by: Jim Kukunas
---
arch/x86/Makefile | 5 +-
include/linux/raid/pq.h | 1 +
lib/raid6/Makefile | 2 +-
lib/raid6/algos.c | 3 +
lib/raid6/recov_avx
13 matches
Mail list logo
