From: Kyle Moffett <mrmacman_g4@mac.com>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: "Michael K. Edwards" <medwards.linux@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Anton Blanchard <anton@samba.org>,
Davide Libenzi <davidel@xmailserver.org>,
Avi Kivity <avi@argo.co.il>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [patch] epoll use a single inode ...
Date: Thu, 8 Mar 2007 20:34:50 -0500 [thread overview]
Message-ID: <8638AE87-6005-4021-98EB-43E55694B0FB@mac.com> (raw)
In-Reply-To: <45EFBA14.9090307@cosmosbay.com>
On Mar 08, 2007, at 02:24:04, Eric Dumazet wrote:
> Kyle Moffett a écrit :
>> Prefetching is also fairly critical on a Power4 or G5 PowerPC
>> system as they have a long memory latency; an L2-cache miss can
>> cost 200+ cycles. On such systems the "dcbt" prefetch instruction
>> brings in a single 128-byte cacheline and has no serializing
>> effects whatsoever, making it ideal for use in a linked-list-
>> traversal inner loop.
>
> OK, 200 cycles...
>
> 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 ?)
Well, PowerPC "dcbt" does prefetch() correctly, it doesn't ever raise
exceptions, doesn't have any side effects, takes only enough CPU to
decode the address, and is ignored if it would have to do anything
other than load the cacheline from RAM. Prefetch streams are halted
when they reach the end of a page boundary (no trapping to the MMU)
and if the TLB entry isn't present then they would asynchronously
abort. This is a suitable prefetch implementation for G5:
#define prefetch(x) __asm__ __volatile__ ("dcbt 0, %0"::"r"(x));
On GCC4+ the "__builtin_prefetch" built-in functions is probably
mildly better tuned for most architectures:
#define PREFETCH_RD 0
#define PREFETCH_WR 1
#define PREFETCH_LOCALITY_NONE 0
#define PREFETCH_LOCALITY_LOW 1
#define PREFETCH_LOCALITY_MED 2
#define PREFETCH_LOCALITY_HIGH 3
#define prefetch(x, args...) __builtin_prefetch(x ,##args)
The pertinent GCC docs:
> This function is used to minimize cache-miss latency by moving data
> into a cache before it is accessed. You can insert calls to
> __builtin_prefetch into code for which you know addresses of data
> in memory that is likely to be accessed soon. If the target
> supports them, data prefetch instructions will be generated. If the
> prefetch is done early enough before the access then the data will
> be in the cache by the time it is accessed.
>
> The value of addr is the address of the memory to prefetch. There
> are two optional arguments, rw and locality. The value of rw is a
> compile-time constant one or zero; one means that the prefetch is
> preparing for a write to the memory address and zero, the default,
> means that the prefetch is preparing for a read. The value locality
> must be a compile-time constant integer between zero and three. A
> value of zero means that the data has no temporal locality, so it
> need not be left in the cache after the access. A value of three
> means that the data has a high degree of temporal locality and
> should be left in all levels of cache possible. Values of one and
> two mean, respectively, a low or moderate degree of temporal
> locality. The default is three.
> for (i = 0; i < n; i++) {
> a[i] = a[i] + b[i];
> __builtin_prefetch (&a[i+j], 1, 1);
> __builtin_prefetch (&b[i+j], 0, 1);
> /* ... */
> }
>
> Data prefetch does not generate faults if addr is invalid, but the
> address expression itself must be valid. For example, a prefetch of
> p->next will not fault if p->next is not a valid address, but
> evaluation will fault if p is not a valid address.
>
> If the target does not support data prefetch, the address
> expression is evaluated if it includes side effects but no other
> code is generated and GCC does not issue a warning.
Cheers,
Kyle Moffett
next prev parent reply other threads:[~2007-03-09 1:36 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <45ED1A3C.6030707@argo.co.il>
2007-03-07 0:37 ` Davide Libenzi
2007-03-07 0:51 ` Linus Torvalds
2007-03-07 1:01 ` Davide Libenzi
2007-03-07 1:27 ` Linus Torvalds
2007-03-07 1:47 ` Davide Libenzi
2007-03-07 6:52 ` Eric Dumazet
2007-03-07 7:15 ` Davide Libenzi
2007-03-07 7:16 ` Eric Dumazet
2007-03-07 8:56 ` Christoph Hellwig
2007-03-07 17:21 ` Linus Torvalds
2007-03-07 17:02 ` Linus Torvalds
2007-03-07 17:31 ` Eric Dumazet
2007-03-07 17:36 ` Eric Dumazet
2007-03-07 17:45 ` Linus Torvalds
2007-03-07 18:06 ` Eric Dumazet
2007-03-07 18:30 ` Linus Torvalds
2007-03-07 18:52 ` Eric Dumazet
2007-03-07 19:07 ` Linus Torvalds
2007-03-07 22:14 ` Anton Blanchard
2007-03-07 22:57 ` Linus Torvalds
2007-03-08 1:25 ` Michael K. Edwards
2007-03-08 2:48 ` Kyle Moffett
2007-03-08 7:24 ` Eric Dumazet
2007-03-08 16:57 ` Valdis.Kletnieks
2007-03-09 1:34 ` Kyle Moffett [this message]
2007-03-09 2:52 ` Anton Blanchard
2007-03-09 2:51 ` Anton Blanchard
2007-03-08 3:20 ` Linus Torvalds
2007-03-08 8:37 ` Michael K. Edwards
2007-03-09 2:46 ` Anton Blanchard
2007-03-08 8:56 ` Christoph Hellwig
2007-03-08 9:42 ` Eric Dumazet
2007-03-08 10:21 ` Christoph Hellwig
2007-03-08 11:11 ` Eric Dumazet
2007-03-08 11:18 ` Christoph Hellwig
2007-03-08 15:52 ` Linus Torvalds
2007-03-08 16:58 ` [PATCH] VFS : Delay the dentry name generation on sockets and pipes Eric Dumazet
2007-03-08 18:29 ` Eric Dumazet
2007-03-09 10:18 ` [PATCH, take2] " Eric Dumazet
2007-03-09 18:22 ` Linus Torvalds
2007-03-10 1:21 ` [PATCH, take3] " Eric Dumazet
2007-03-08 20:00 ` [patch] epoll use a single inode Bob Copeland
[not found] <45ED046A.5010508@argo.co.il>
2007-03-06 7:27 ` Davide Libenzi
2007-03-05 21:25 Davide Libenzi
2007-03-05 21:52 ` Eric Dumazet
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=8638AE87-6005-4021-98EB-43E55694B0FB@mac.com \
--to=mrmacman_g4@mac.com \
--cc=akpm@linux-foundation.org \
--cc=anton@samba.org \
--cc=avi@argo.co.il \
--cc=dada1@cosmosbay.com \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=medwards.linux@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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
all inboxes | Powered by JetHome®