On Tue, 06 Nov 2018, Andrew Morton wrote:
It would be interesting to know precisely which stat fields the
database-which-shall-not-be-named is looking for. Then we could cook
up a very whizzy way of getting at the info.
The ctxt field, afaik. In any case they have been able to work around
the bottleneck. I'm not sure if that is the case for Waiman, however.
A downside of the stat2 approach is that applications will need to be
rebuilt. And hopefully when people do this, they'll open
"/etc/my-app-name/symlink-to-proc-stat" (or use per-application config)
so they won't need a rebuild when we add /proc/stat3!
A /proc/change-how-stat-works tunable would avoid the need to rebuild
applications. But if a system still has some applications which want
the irq info then that doesn't work.
It's all very sad, really.
btw,
+The stat2 file acts as a performance alternative to /proc/stat for workloads
+and systems that care and are under heavy irq load. In order to to be completely
+compatible, /proc/stat and /proc/stat2 are identical with the exception that the
+later will show 0 for any (hard)irq-related fields. This refers particularly
"latter"
+to the "intr" line and 'irq' column for that aggregate in the cpu line.
btw2, please quantify "poor performance". That helps us determine how
much we care about all of this!
Up to a quarter of a second is what was reported as being spent every time
/proc/stat is used. This is with 1k cores and 4k interrupts.
Thanks,
Davidlohr
