From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 15 Feb 2013 11:15:26 -0500 Subject: using prefetch In-Reply-To: Your message of "Fri, 15 Feb 2013 12:16:02 +0200." References: Message-ID: <10482.1360944926@turing-police.cc.vt.edu> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Fri, 15 Feb 2013 12:16:02 +0200, Kevin Wilson said: > Is the prefetch operation synchronous ? I mean, after calling it, are > we gauranteed that the variable is > indeed in the cache ? No, the whole *point* is that it's asynchronous. You issue the prefetch several lines of code before you need it to be in cache, so that you can get several lines of hopefully not data-dependent code to run while the cache line fetch happens, rather than take a stall when you reference the variable. The prefetch may in fact not complete in time, but at worst you end up just stalling for a cache miss the same as you would have otherwise. > According to this logic, anywhere that we want to call skb_shinfo(skb) > we better do a prefetch before. No, because most references to skb will be cache-hot because you're in the middle of the IP stack, which touches the skb struct all over the place, and therefor it's probably in L2 already. > In fact, if we prefetch any variable that we want to use then we end up > with performance boost. Nope. Not as true as you might think. If you play around with the 'perf' command you'll find out that on modern processors you'll see a 98% or so hit rate on the L2 cache - so 98% of the time you'll *waste* a cycle issuing the opcode needlessly. If you look carefully at some of the other structs in the net/ subtree, you'll see where they've put variables together so that once you reference one field of the struct, all/most of the needed stuff gets sucked in on the same cache line. That's probably more productive than trying to add prefetch calls all over the place. > So - any hints, what are the guidlines for using prefetch()? Only use it if you have good reason to believe that you *will* need that variable (in other words, it's not in the unlikely half of an if statement or somehting) *and* there's a good chance that the variable/memory is cache-cold. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130215/e31a61db/attachment.bin