All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/2] Btrfs: serialize flushers in reserve_metadata_bytes
Date: Fri, 10 Jun 2011 13:49:48 -0400	[thread overview]
Message-ID: <4DF2593C.7040107@redhat.com> (raw)
In-Reply-To: <20110610174759.GS12709@twin.jikos.cz>

On 06/10/2011 01:47 PM, David Sterba wrote:
> On Thu, Jun 09, 2011 at 08:00:15PM +0200, David Sterba wrote:
>> On Thu, Jun 09, 2011 at 10:00:42AM -0400, Josef Bacik wrote:
>>> We're not trying to be perfect here, we're trying to be fast :).
>>
>> Be even faster with smp_rmb() :)
> 
> Arne made me think about this again. Let's analyze it in more detail:
> 
> The read side, if(delalloc_bytes), utilizes a full barrier, which will
> force all cpus to flush pending reads and writes. This will ensure 'if'
> will see a fresh value.
> 
> However, there is no pairing write barrier and the write flush will
> happen at some point in time, (delalloc_bytes += len), but completely
> unsynchronized with the read side.
> 
> The smp_mb barrier has no desired synchonization effect. Moreover, it
> has a performance hit.
> 
> 
> Doing it right with barriers would mean to add smp_rmb before the
> if(...) and smp_wmb after the "delalloc_bytes =", but only in the case
> the variable is solely synchronized via barriers. Not our case. There is
> the spinlock.
> 
> As strict correctness is not needed here, you admit that delalloc_bytes
> might not correspond to the state of fs_info->delalloc_inodes and this
> is not a problem. Fine. But then you do not need the smp_mb. The value
> of delalloc_bytes will be "random" (ie. unsynchronized), with or without
> the barrier. Please drop it from the patch.

I just used the spin lock.

Josef

      reply	other threads:[~2011-06-10 17:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 20:44 [PATCH 0/2] Fix ENOSPC regression Josef Bacik
2011-06-07 20:44 ` [PATCH 1/2] Btrfs: do transaction space reservation before joining the transaction Josef Bacik
2011-06-07 20:44 ` [PATCH 2/2] Btrfs: serialize flushers in reserve_metadata_bytes Josef Bacik
2011-06-09  9:45   ` David Sterba
2011-06-09 14:00     ` Josef Bacik
2011-06-09 18:00       ` David Sterba
2011-06-10 17:47         ` David Sterba
2011-06-10 17:49           ` Josef Bacik [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=4DF2593C.7040107@redhat.com \
    --to=josef@redhat.com \
    --cc=linux-btrfs@vger.kernel.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.