linux-kernel - Re: [PATCH v2 1/7] 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]

Date:	Thu, 14 Jul 2016 12:16:19 -0400
From:	Waiman Long <waiman.long@....com>
To:	Tejun Heo <tj@...nel.org>
CC:	Jan Kara <jack@...e.cz>, Alexander Viro <viro@...iv.linux.org.uk>,
	Jan Kara <jack@...e.com>,
	Jeff Layton <jlayton@...chiereds.net>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Christoph Lameter <cl@...ux-foundation.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 v2 1/7] lib/dlock-list: Distributed and lock-protected
 lists

On 07/14/2016 10:51 AM, Tejun Heo wrote:
> Hello, Jan.
>
> On Thu, Jul 14, 2016 at 04:35:47PM +0200, Jan Kara wrote:
>>>> The current use case only need to use the regular lock functions. You are
>>>> right that future use cases may require an irqsafe version of locks. I can
>>>> either modify the code now to allow lock type selection at init time, for
>>>> example, or defer it as a future enhancement when the need arises. What do
>>>> you think?
>>> The bulk of performance gain of dlist would come from being per-cpu
>>> and I don't think it's likely that we'd see any noticeable difference
>>> between irq and preempt safe operations.  Given that what's being
>>> implemented is really low level operations, I'd suggest going with
>>> irqsafe from the get-go.
>> I'm not sure here. i_sb_list for which percpu lists will be used is bashed
>> pretty heavily under some workloads and the cost of additional interrupt
>> disabling&  enabling may be visible under those loads. Probably not in the
>> cases where you get a boost from percpu lists but if the workload is mostly
>> single-threaded, additional cpu cost may be measurable. So IMO we should
>> check whether a load which creates tons of empty inodes in tmpfs from a
>> single process doesn't regress with this change.
> Sure, if it actually matters, we can always create separate preempt /
> irq variants.
>
> Thanks.
>

I think having the irqsafe version of add and delete function variants 
is the way to go to ensure that we don't cause performance regression 
for codes that don't need the overhead of irqsave and irqrestore.

Cheers,
Longman