[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1604131001020.3673@east.gentwo.org>
Date: Wed, 13 Apr 2016 10:03:30 -0500 (CDT)
From: Christoph Lameter <cl@...ux.com>
To: Waiman Long <Waiman.Long@....com>
cc: Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.com>,
Jeff Layton <jlayton@...chiereds.net>,
"J. Bruce Fields" <bfields@...ldses.org>,
Tejun Heo <tj@...nel.org>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Andi Kleen <andi@...stfloor.org>,
Dave Chinner <dchinner@...hat.com>,
Boqun Feng <boqun.feng@...il.com>,
Scott J Norton <scott.norton@....com>,
Douglas Hatch <doug.hatch@....com>
Subject: Re: [PATCH v7 1/4] lib/percpu-list: Per-cpu list with associated
per-cpu locks
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?
Powered by blists - more mailing lists