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

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

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