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