linux-kernel - Re: [rfc][patch 3/3] x86: optimise barriers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <470F337A.9090205@aitel.hist.no>
Date:	Fri, 12 Oct 2007 10:42:34 +0200
From:	Helge Hafting <helge.hafting@...el.hist.no>
To:	Jarek Poplawski <jarkao2@...pl>
CC:	Nick Piggin <npiggin@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <ak@...e.de>
Subject: Re: [rfc][patch 3/3] x86: optimise barriers

Jarek Poplawski wrote:
> On 04-10-2007 07:23, Nick Piggin wrote:
>   
>> According to latest memory ordering specification documents from Intel and
>> AMD, both manufacturers are committed to in-order loads from cacheable memory
>> for the x86 architecture. Hence, smp_rmb() may be a simple barrier.
>>     
> ...
>
> Great news!
>
> First it looks like a really great thing that it's revealed at last.
> But then... there is probably some confusion: did we have to use
> ineffective code for so long?
>   
You could have tried the optimization before, and
gotten better performance. But if without solid knowledge that
the optimization is _valid_, you risk having a kernel
that performs great but suffer the occational glitch and
therefore is unstable and crash the machine "now and then".
This sort of thing can't really be figured out by experimentation, because
the bad cases might happen only with some processors, some
combinations of memory/chipsets, or with some minimum
number of processors.  Such problems can be very hard
to find, especially considering that other plain bugs also
cause crashes.

Therefore, the "ineffective code" was used because it was
the only safe alternative. Now we know, so now we may optimize.


Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/