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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <57902719.8060903@hpe.com>
Date:	Wed, 20 Jul 2016 21:36:25 -0400
From:	Waiman Long <waiman.long@....com>
To:	Christoph Lameter <cl@...ux.com>
CC:	Tejun Heo <tj@...nel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Jan Kara <jack@...e.com>,
	Jeff Layton <jlayton@...chiereds.net>,
	"J. Bruce Fields" <bfields@...ldses.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 v3 1/4] lib/dlock-list: Distributed and lock-protected
 lists

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