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:   Mon, 21 Sep 2020 09:49:54 +1000
From:   Dave Chinner <david@fromorbit.com>
To:     Jan Kara <jack@suse.cz>
Cc:     Oleg Nesterov <oleg@redhat.com>, peterz@infradead.org,
        Boaz Harrosh <boaz@plexistor.com>,
        Hou Tao <houtao1@huawei.com>, Ingo Molnar <mingo@redhat.com>,
        Will Deacon <will@kernel.org>, Dennis Zhou <dennis@kernel.org>,
        Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH] locking/percpu-rwsem: use this_cpu_{inc|dec}() for
 read_count
Message-ID: <20200920234954.GY12096@dread.disaster.area>
References: <b885ce8e-4b0b-8321-c2cc-ee8f42de52d4@huawei.com>
 <ddd5d732-06da-f8f2-ba4a-686c58297e47@plexistor.com>
 <20200917120132.GA5602@redhat.com>
 <20200918090702.GB18920@quack2.suse.cz>
 <20200918100112.GN1362448@hirez.programming.kicks-ass.net>
 <20200918101216.GL35926@hirez.programming.kicks-ass.net>
 <20200918104824.GA23469@redhat.com>
 <20200918110310.GO1362448@hirez.programming.kicks-ass.net>
 <20200918130914.GA26777@redhat.com>
 <20200918132635.GI18920@quack2.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200918132635.GI18920@quack2.suse.cz>
Precedence: bulk

On Fri, Sep 18, 2020 at 03:26:35PM +0200, Jan Kara wrote:
> On Fri 18-09-20 15:09:14, Oleg Nesterov wrote:
> > On 09/18, Peter Zijlstra wrote:
> > > > But again, do we really want this?
> > >
> > > I like the two counters better, avoids atomics entirely, some archs
> > > hare horridly expensive atomics (*cough* power *cough*).
> > 
> > I meant... do we really want to introduce percpu_up_read_irqsafe() ?
> > 
> > Perhaps we can live with the fix from Hou? At least until we find a
> > "real" performance regression.
> 
> I can say that for users of percpu rwsem in filesystems the cost of atomic
> inc/dec is unlikely to matter. The lock hold times there are long enough
> that it would be just lost in the noise.

I'm not sure that is correct. We do an inc/dec pair per AIO, so if
we are running millions of IOPS through the AIO subsystem, then the
cost of doing millions of extra atomic ops every second is going to
be noticable...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com