On 04/07/2016 12:06 PM, Tejun Heo wrote:
Hello, Waiman.
On Thu, Apr 07, 2016 at 11:58:13AM -0400, Waiman Long wrote:
We can certainly make it watertight. However, that will certainly require
adding performance overhead in the percpu stats update fast path which I am
not willing to pay.
There are multiple options depending on the specific balance you want
to hit. Reset can be made very heavy (involving RCU sync operation)
to make hot path overhead minimal, local locking or atomic ops can
also be used which while more expensive than this_cpu_*() ops still
avoids cacheline bouncing.
The purpose of this stat counters reset functionality is to allow developers
to reset the stat counters, run certain workload and see how things are
going in the kernel when the workload completes assuming that those stat
counters are exposed via sysfs, debugfs, etc. The developers can certainly
check the stat counters after the reset to make sure that they are properly
reset. So I don't think we need an airtight way of doing it. If you have
scenarios in your mind that require airtight reset of the stat counters,
please let me know and I will see what I can do about it.
No matter what, don't create something which can yield a completely
surprising result once in a blue moon. You might think it's okay
because the likelihood is low but that just means that the resulting
malfunctions will be that much more obscure and difficult to
reproduce.
Thanks.
As long as atomic reset is an optional feature that caller can choose at
init time, I am OK to provide this functionality. I just don't want it
to be the default because of the performance overhead.
Cheers,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
