Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 27 Oct 2020 08:59:23 +1100
From:   Dave Chinner <david@fromorbit.com>
To:     Davidlohr Bueso <dave@stgolabs.net>
Cc:     viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
        peterz@infradead.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH] fs/dcache: optimize start_dir_add()
Message-ID: <20201026215923.GA306023@dread.disaster.area>
References: <20201022211650.25045-1-dave@stgolabs.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201022211650.25045-1-dave@stgolabs.net>
Precedence: bulk

On Thu, Oct 22, 2020 at 02:16:50PM -0700, Davidlohr Bueso wrote:
> Considering both end_dir_add() and d_alloc_parallel(), the
> dir->i_dir_seq wants acquire/release semantics, therefore
> micro-optimize for ll/sc archs and use finer grained barriers
> to provide (load)-ACQUIRE ordering (L->S + L->L). This comes
> at no additional cost for most of x86, as sane tso models will
> have a nop for smp_rmb/smp_acquire__after_ctrl_dep.
> 
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> ---
> Alternatively I guess we could just use cmpxchg_acquire().

Please us cmpxchg_acquire() so that people who have no clue what the
hell smp_acquire__after_ctrl_dep() means or does have some hope of
understanding of what objects the ordering semantics in the function
actually apply to....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com