All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Paul Walmsley <paul@pwsan.com>
Cc: Russ Dill <russ.dill@gmail.com>,
	Artem Bityutskiy <dedekind@yandex.ru>,
	David Hagood <david.hagood@gmail.com>,
	linux-omap@vger.kernel.org
Subject: Re: Benchmarking: POP flash vs. MMC?
Date: Mon, 6 Apr 2009 03:23:20 -0700	[thread overview]
Message-ID: <200904060323.21127.david-b@pacbell.net> (raw)
In-Reply-To: <alpine.DEB.2.00.0904060402140.22223@utopia.booyaka.com>

On Monday 06 April 2009, Paul Walmsley wrote:
> Hi David
> 
> On Mon, 6 Apr 2009, David Brownell wrote:
> 
> > On Monday 06 April 2009, Russ Dill wrote:
> > > Also, it appears from looking an the openzoom git, there are some
> > > patches to add DMA support in, but I'm not sure what effect they have.
> > 
> > We had asked for some benchmark data -- anything! -- to get a
> > handle on that, and the prefetch/etc engine; nothing forthcoming,
> > so far.
> 
> We'd also have to make sure that the comparison is between the linux-omap 
> kernel and the OMAPZoo kernel, rather than o-z PIO vs. o-z DMA.  The 
> OMAPZoom kernel doesn't post any device register writes.  That should 
> cause any driver using PIO to drag, compared to the l-o kernel.

I'd think the first thing to check is two linux-omap PIO flavors:
with vs without the prefetch/postwrite engine.  Benchmarking DMA
would be a separate issue.  Ditto comparing kernels with/without
write posting.

I've benchmarked small DMA transfers and it's rather hard to get
them faster than io{read,write}32_rep().  Overhead of DMA mapping
and just DMA setup/teardown/complete is annoyingly high.  While
bus overheads aren't large.

Puzzle:  get a dma_copypage() to work faster than copy_page().
Or a dma_clear_page() faster than clear_page().  Not easy...

- Dave

  reply	other threads:[~2009-04-06 10:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-03 21:24 Benchmarking: POP flash vs. MMC? david.hagood
2009-04-04  0:57 ` Russ Dill
2009-04-04  2:52   ` David Hagood
2009-04-04  4:16     ` Russ Dill
2009-04-05 22:53       ` David Brownell
2009-04-06  7:41     ` Artem Bityutskiy
2009-04-06  8:13       ` Russ Dill
2009-04-06  9:07         ` Artem Bityutskiy
2009-04-06  9:59         ` David Brownell
2009-04-06 10:08           ` Paul Walmsley
2009-04-06 10:23             ` David Brownell [this message]
2009-04-06 10:34               ` Paul Walmsley
2009-04-06 10:48                 ` David Brownell
2009-04-07 17:22                   ` Tony Lindgren
2009-04-07 12:09             ` Woodruff, Richard

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=200904060323.21127.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=david.hagood@gmail.com \
    --cc=dedekind@yandex.ru \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=russ.dill@gmail.com \
    /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.