linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Peter Fordham <peter.fordham@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: spinlocks in ext4
Date: Thu, 11 Oct 2012 20:17:32 -0400	[thread overview]
Message-ID: <20121012001732.GA3990@thunk.org> (raw)
In-Reply-To: <CAK5=ZRJt3KCQniUA+-E4kn_51nFvB34796wOoG4vrmzU5nfwOA@mail.gmail.com>

On Thu, Oct 11, 2012 at 11:37:46AM -0700, Peter Fordham wrote:
> On 8 October 2012 18:10, Theodore Ts'o <tytso@mit.edu> wrote:
> > How expensive are memory barriers on ARM, anyway?
> 
> The performance monitors seem to be telling me that a DMB just after a
> store which misses in the L1 & L2, (causing an eviction of a clean
> line and a line-fill, I assume) takes over 100 cycles.

If we assume a 1GHz clock, 100 cycles is 0.1 microseconds (100ns).  A
4k read on an eMMC device (what I assume you are using) is about 5ms.
A super expensive PCIe attached flash has a read latency of around
20-50 microseconds.  Read latency for an SSD is around 1ms.

> I'm seeing a 20% slow down in ext4 performance when enabling SMP on my
> device. I'm starting to think there might be issues with the memory
> system.

So what are you measuring and how are you measuring it?  If 0.1
microseconds is significant, it must be something where everything is
in cache, and you're never hitting the storage device.

More to the point, as Arjan pointed out to me on Google+, using a
mutex is going to add at least one, and probably more, memory barriers
(due to the locks needed by the scheduler) *plus* the scheduling
overhead.  So your claim that using a mutex is superior to using
spinlocks makes absolutely no sense.

					- Ted

      reply	other threads:[~2012-10-12  0:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-08 23:33 spinlocks in ext4 Peter Fordham
2012-10-09  0:54 ` Theodore Ts'o
2012-10-09  1:10   ` Theodore Ts'o
2012-10-11 18:37     ` Peter Fordham
2012-10-12  0:17       ` Theodore Ts'o [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=20121012001732.GA3990@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=peter.fordham@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 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).