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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
