Message-ID: <570E8620.60508@hpe.com>
Date: Wed, 13 Apr 2016 13:47:12 -0400
From: Waiman Long <waiman.long@hpe.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: Christoph Lameter <cl@linux.com>
CC: Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.com>,
        Jeff Layton <jlayton@poochiereds.net>,
        "J. Bruce Fields" <bfields@fieldses.org>, Tejun Heo <tj@kernel.org>,
        <linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
        Andi Kleen <andi@firstfloor.org>, Dave Chinner <dchinner@redhat.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Scott J Norton <scott.norton@hpe.com>,
        Douglas Hatch <doug.hatch@hpe.com>
Subject: Re: [PATCH v7 1/4] lib/percpu-list: Per-cpu list with associated
 per-cpu locks
References: <1460501686-37096-1-git-send-email-Waiman.Long@hpe.com> <1460501686-37096-2-git-send-email-Waiman.Long@hpe.com> <alpine.DEB.2.20.1604131001020.3673@east.gentwo.org>
In-Reply-To: <alpine.DEB.2.20.1604131001020.3673@east.gentwo.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2016 17:47:22.8714 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0308
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 859
Lines: 20

On 04/13/2016 11:03 AM, Christoph Lameter wrote:
> On Tue, 12 Apr 2016, Waiman Long wrote:
>
>> List entry insertion is strictly per cpu. List deletion, however, can
>> happen in a cpu other than the one that did the insertion. So we still
>> need lock to protect the list. Because of that, there may still be
>> a small amount of contention when deletion is being done.
> Ok then the list is not per cpu anymore. Can we call this something else
> please to avoid confusion? Spinlocks in per cpu structures are a bit
> confusing otherwise. Seems that there is no requirement that the list can
> only be accessed from a single cpu so its not per cpu per se anymore.
>
> Maybe lock-list instead of percpu-list?
>

I am fine with a name change. I am not that good in naming stuff. How 
about distributed and locked list, or dlock_list in short?

Cheers,
Longman