Hello, Jan.
On Thu, Jul 14, 2016 at 04:35:47PM +0200, Jan Kara wrote:
Sure, if it actually matters, we can always create separate preempt /I'm not sure here. i_sb_list for which percpu lists will be used is bashedThe current use case only need to use the regular lock functions. You areThe bulk of performance gain of dlist would come from being per-cpu
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?
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.
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.
irq variants.
Thanks.