[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200703081657.l28GvPSm010589@turing-police.cc.vt.edu>
Date: Thu, 08 Mar 2007 11:57:25 -0500
From: Valdis.Kletnieks@...edu
To: Eric Dumazet <dada1@...mosbay.com>
Cc: Kyle Moffett <mrmacman_g4@....com>,
"Michael K. Edwards" <medwards.linux@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Anton Blanchard <anton@...ba.org>,
Davide Libenzi <davidel@...ilserver.org>,
Avi Kivity <avi@...o.co.il>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [patch] epoll use a single inode ...
On Thu, 08 Mar 2007 08:24:04 +0100, Eric Dumazet said:
>
> But what is the cost of the conditional branch you added in prefetch(x) ?
>
> if (!x) return;
>
> (correctly predicted or not, but do powerPC have a BTB ?)
>
> About the NULL 'potential problem', maybe we could use a dummy nil (but
> mapped) object, and use its address in lists, ie compare for &nil instead of
> NULL. This would avoid :
>
> - The conditional test in some prefetch() implementations
> - The potential TLB problem with the NULL value.
You avoid those two, but add the very high likelyhood that a statement of the
form 'if (!x) {....}' will creep back in and bug out. I doubt that changing
the form of a basic C idiom to save a few cycles is worth it, especially when
the (!x) form can be tested without a memory fetch, but (x != nil) may require
fetching 'nil' (remember - the x86 is a very popular chipset, but register
starved - if the loop is any size at all, 'nil' may require a reload each
time around, costing you the win you thought you had....
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists