Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists

[Waiman Long <waiman.long@hpe.com>]

On 07/20/2016 08:48 PM, Christoph Lameter wrote:
> On Wed, 20 Jul 2016, Waiman Long wrote:
>
>> Christoph, are you OK with Tejun's request to revert the name back to
>> percpu_list? Or do you still think the current name is better?
> The percpu structure contains a spinlock and may be remotely accessed? You
> are aware that other percpu variables that share the same cacheline will
> be negatively impacted by accesses from other processors?

The spinlock can be remotely accessed during deletion as well as the 
iteration of all the percpu lists. Iteration of all the percpu data is 
not a new thing as it may also be done in percpu_counter when calling 
percpu_counter_sum().

Yes, remote access can have a negative performance impact on the access 
of other percpu data that happen to reside in the same cacheline.

> The role of percpu areas are to have memory areas where the code can
> expect that cachelines are exclusively there for that processor.
>
> How frequent are the remote accesses? If this is rare then ok.

I can't say how often that will happen for the dlock list. If the thread 
that create the inodes does not migrate to other CPU, the deletion of 
the inode should also happens in the same CPU.

One way to reduce the performance impact is to make the percpu head 
structure cacheline aligned at the expense of some wasted space. I could 
add an additional parameter to alloc_dlock_list_head() to force 
cacheline alignment if the caller wish to do so. What do think about that?

Cheers,
Longman