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
--
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
