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: <2DDDD55D-4445-4565-9384-4E4BE7B41D7D@mac.com>
Date:	Wed, 26 Sep 2007 11:23:19 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Erez Zadok <ezk@...sunysb.edu>
Cc:	"Kok, Auke" <auke-jan.h.kok@...el.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	viro@....linux.org.uk, hch@...radead.org
Subject: Re: [PATCH 10/25] Unionfs: add un/likely conditionals on copyup ops

On Sep 26, 2007, at 09:40:20, Erez Zadok wrote:
> In message <46F9E0EC.3010105@...el.com>, "Kok, Auke" writes:
>> I've been told several times that adding these is almost always  
>> bogus - either it messes up the CPU branch prediction or the  
>> compiler/CPU just does a lot better at finding the right way  
>> without these hints.
>>
>> Adding them as a blanket seems rather strange. Have you got any  
>> numbers that this really improves performance?
>
> Auke, that's a good question, but I found it hard to find any info  
> about it.  There's no discussion on it in Documentation/, and very  
> little I could find elsewhere.  I did see one url explaining what  
> un/likely does precisely, but no guidelines.  My understanding is  
> that it can improve performance, as long as it's used carefully  
> (otherwise it may hurt performance).

Hmm, even still I agree with Auke, you probably use it too much.


> Recently we've done a full audit of the entire code, and added un/ 
> likely where we felt that the chance of succeeding is 95% or better  
> (e.g., error conditions that should rarely happen, and such).

Actually due to the performance penalty on some systems I think you  
only want to use it if the chance of succeeding is 99% or better, as  
the benefit if predicted is a cycle or two and the harm if  
mispredicted can be more than 50 cycles, depending on the CPU.  You  
should also remember than in filesystems many "failures" are  
triggered by things like the ld.so library searches, where it  
literally calls access() 20 different times on various possible paths  
for library files, failing the first 19.  It does this once for each  
necessary library.

Typically you only want to add unlikely() or likely() for about 2  
reasons:
   (A)  It's a hot path and the unlikely case is just going to burn a  
bunch of CPU anyways
   (B)  It really is extremely unlikely that it fails (Think physical  
hardware failure)

Anything else is just bogus.

Cheers,
Kyle Moffett

-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ