linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: SMP performance question(Re: USB mass storage and ARM cache coherency)
Date: Sun, 28 Feb 2010 22:27:43 +0000	[thread overview]
Message-ID: <1267396063.4485.4.camel@e102109-lin.cambridge.arm.com> (raw)
In-Reply-To: <10d816431002262332ke92737cvafcbff63fbbb6c85@mail.gmail.com>

On Sat, 2010-02-27 at 07:32 +0000, Lin Mac wrote:
> > My latest solution - http://bit.ly/apJv3O - is to use dummy
> > read-for-ownership or write-for-ownership accesses in the DMA cache
> > flushing functions to force cache line migration from the other CPUs.
> > Our current benchmarks only show around 10% disc throughput penalty
> > compared to the normal SMP case (compared to the UP case the penalty is
> > bigger but that's due to other things).
> 
> So it sounds like the performance of UP > __Normal SMP__ > RFO/WFO + SMP.
> 
> Maybe I've got the wrong expection, for I'm not experienced in SMP.
> But I do expect the performance of  __Normal SMP__ should at least >=
> UP's.
> 
> Why the performance of UP would > __Normal SMP__?
> And what's the __Normal SMP__ definition?

By normal SMP I meant an unpatched kernel but with data corruption for
DMA transfers.

Our tests were for I/O bound operations (DMA transfers) where no matter
how many CPUs you add, the bottleneck is still the DMA engine. Adding
more CPUs could make things slightly worse by introducing extra
contention (and spinlocks, cache line ping-pong'ing).


-- 
Catalin

      reply	other threads:[~2010-02-28 22:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-27  7:32 SMP performance question(Re: USB mass storage and ARM cache coherency) Lin Mac
2010-02-28 22:27 ` Catalin Marinas [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=1267396063.4485.4.camel@e102109-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).