All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: "Steven J. Hill" <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] MIPS: lib: Optimize partial checksum ops using prefetching.
Date: Tue, 21 Jan 2014 21:49:38 +0100	[thread overview]
Message-ID: <20140121204938.GW14169@linux-mips.org> (raw)
In-Reply-To: <1390321122-25634-1-git-send-email-Steven.Hill@imgtec.com>

On Tue, Jan 21, 2014 at 10:18:42AM -0600, Steven J. Hill wrote:

> From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> 
> Use the PREF instruction to optimize partial checksum operations.

Prefetch operations may cause obscure bus error exceptions on some systems
such as Malta, for example, when prefetching beyond the end of memory.
It may also mean memory regions that are just undergoing a DMA transfer
are being brought back into cache.

This pretty much means that pref is only safe to use on cache-coherent
systems.

Those are the very same reasons that are making pref headache for memcpy.

Performance tuning is another can of worms.  On those platforms that I've
benchmarked code with and without pref on, it was very hard to predict
if pref was actually an advantage.  If data that is not going to be
used is prefetch, pref wastes an issue slot, wastes instruction bandwith
and in the end makes things slower.  If data is not prefetched early
enough, same kind of issue.  And in the end PREF and MT were invented
to solve the same kind of fundamental problem: memory is slow and slower
on embedded.  For both solutions the results are extremly dependent on
workload.

Cheers,

  Ralf

  parent reply	other threads:[~2014-01-21 20:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-21 16:18 [PATCH] MIPS: lib: Optimize partial checksum ops using prefetching Steven J. Hill
2014-01-21 17:37 ` Florian Fainelli
2014-01-21 18:25 ` David Daney
2014-01-21 20:16   ` Steven J. Hill
2014-01-21 20:25     ` Florian Fainelli
2014-01-21 20:49 ` Ralf Baechle [this message]
2014-01-21 20:58   ` Steven J. Hill
2014-01-21 20:58     ` Steven J. Hill
2014-01-21 21:03     ` David Daney

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=20140121204938.GW14169@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=Steven.Hill@imgtec.com \
    --cc=linux-mips@linux-mips.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.