Date: Wed, 19 Jul 2017 15:58:33 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
        Elena Reshetova <elena.reshetova@intel.com>,
        linux-kernel@vger.kernel.org, peterz@infradead.org,
        gregkh@linuxfoundation.org, mingo@redhat.com, adobriyan@gmail.com,
        serge@hallyn.com, arozansk@redhat.com, keescook@chromium.org,
        Hans Liljestrand <ishkamiel@gmail.com>,
        David Windsor <dwindsor@gmail.com>
Subject: Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to
 refcount_t
Message-Id: <20170719155833.641a283467bf6b89a7d2e56b@linux-foundation.org>
In-Reply-To: <20170719225427.GD14395@linux-80c1.suse>
References: <1499417992-3238-1-git-send-email-elena.reshetova@intel.com>
        <1499417992-3238-2-git-send-email-elena.reshetova@intel.com>
        <87bmottgo4.fsf@xmission.com>
        <20170719153546.37567fbf77861653172fa263@linux-foundation.org>
        <20170719225427.GD14395@linux-80c1.suse>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 861
Lines: 22

On Wed, 19 Jul 2017 15:54:27 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:

> On Wed, 19 Jul 2017, Andrew Morton wrote:
> 
> >I do rather dislike these conversions from the point of view of
> >performance overhead and general code bloat.  But I seem to have lost
> >that struggle and I don't think any of these are fastpath(?).
> 
> Well, since we now have fd25d19 (locking/refcount: Create unchecked atomic_t
> implementation), performance is supposed to be ok.

Sure, things are OK for people who disable the feature.

But for people who want to enable the feature we really should minimize
the cost by avoiding blindly converting sites which simply don't need
it: simple, safe, old, well-tested code.  Why go and slow down such
code?  Need to apply some common sense here...

> It would be lovely to have
> some actual numbers nonetheless.

Very much so.