On 24-09-20, 17:10, Lukasz Luba wrote:
Because of supporting this reset file, the code is going to be a bit
complex
I will say not very straight forward, but it isn't complex as well.
and also visited from the scheduler. I don't know if the
config for stats is enabled for production kernels but if yes,
then forcing all to keep that reset code might be too much.
For the engineering kernel version is OK.
I am not sure either if they are enabled for production kernels, but even if it
then also this code won't hit performance.
I would say for most normal checks these sysfs stats are very useful.
If there is a need for investigation like you described, the trace
event is there, just have to be enabled. Tools like LISA would
help with parsing the trace and mapping to some plots or even
merging with scheduler context.
Right, but stats is much easier in my opinion and providing this reset
functionality does make it easier to track. And that it is already there now.
From time to time some engineers are asking why the stats
don't show the values (missing fast-switch tracking). I think
they are interested in a simple use case, otherwise they would use the
tracing.
Right and I completely agree with that and so this patchset. I think there
aren't any serious race conditions here that would make things bad for anyone
and that this patchset will eventually get in after a little rearrangement.