All of lore.kernel.org
 help / color / mirror / Atom feed
From: wkevils@gmail.com (Kevin Wilson)
To: kernelnewbies@lists.kernelnewbies.org
Subject: using prefetch
Date: Fri, 15 Feb 2013 22:18:43 +0200	[thread overview]
Message-ID: <CAGXs5wUm9nZsONHEMb7W1Ja_CuzmbGC-hrEexL7fxrMgE2hmHA@mail.gmail.com> (raw)
In-Reply-To: <20130215164224.GA2428@grml>

Thanks!
KW


On Fri, Feb 15, 2013 at 6:42 PM,
<michi1@michaelblizek.twilightparadox.com> wrote:
> Hi!
>
> On 12:16 Fri 15 Feb     , Kevin Wilson wrote:
> ...
>> AFAIK, what prefetch does is get a variable from memory and put it in
>> cache (L2 cache I believe).
>
> Yes, this is true. See:
> http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Other-Builtins.html
> I am not so sure about the cache level it is fetched to.
>
>> Is the prefetch operation synchronous ? I mean, after calling it, are
>> we gauranteed that the variable is
>> indeed in the cache ?
>
> No, the variable definitely not guaranteed to be in the cache. This would not
> make any sense. The purpose of the prefetch is to fetch data in background
> while executing something else.
>
> Actually it is not guaranteed to fetch anything at all. The target cpu might
> not support the feature at all. Even if it does there are cases where it will
> not be prefetched, e.g. when it triggers a page fault. Also the cpu itself
> might decide not to do the prefetch, e.g. when the cache line is present (and
> locked by cache coherency) in the cache of a different cpu/core.
>
>> So this is probably for improving performance, assuming that you will
>> need this variable in the near
>> future.
>> The comment there says:
>> /* prefetch skb_end_pointer() to speedup skb_shinfo(skb) */
>>
>> According to this logic, anywhere that we want to call skb_shinfo(skb)
>> we better do a prefetch before.
>>
>> In fact, if we prefetch any variable that we want to use then we end up
>> with performance boost.
>>
>> So - any hints, what are the guidlines for using prefetch()?
>
> You really should *not* prefetch() all variables you want to use. Prefetch
> itself generates code which needs cpu cycles. It can quickly make your program
> slower. Use it only in places where
> - the data is very unlikely to be in the cache of either the current or any
>   other cpu in the system *and*
> - you can add the prefetch instruction at least 100ns before the actual use
>
> Also, if you access a reasonably large memory array sequentially (either
> forward or backward), you should not use prefetch() at all. The cpus have
> hardware prefetchers which are faster in this case.
>
>
> A general advise for performance optimisation: run benchmarks
>
>         -Michi
> --
> programing a layer 3+4 network protocol for mesh networks
> see http://michaelblizek.twilightparadox.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

      reply	other threads:[~2013-02-15 20:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 10:16 using prefetch Kevin Wilson
2013-02-15 16:15 ` Valdis.Kletnieks at vt.edu
2013-02-15 16:42 ` michi1 at michaelblizek.twilightparadox.com
2013-02-15 20:18   ` Kevin Wilson [this message]

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=CAGXs5wUm9nZsONHEMb7W1Ja_CuzmbGC-hrEexL7fxrMgE2hmHA@mail.gmail.com \
    --to=wkevils@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.