On Tue, 24 Apr 2018 09:18:59 +0300 Alexey Dobriyan <adobri...@gmail.com> wrote:
> On Mon, Apr 23, 2018 at 10:54:18PM -0700, David Rientjes wrote: > > On Sat, 21 Apr 2018, Alexey Dobriyan wrote: > > > > > > On Thu, Apr 19, 2018 at 04:23:02PM -0700, Joel Fernandes (Google) wrote: > > > > > Can we not just remove per-IRQ stats from /proc/stat (since I gather > > > > > from this discussion it isn't scalable), and just have applications > > > > > that need per-IRQ stats use /proc/interrupts ? > > > > > > > > If you can prove noone is using them in /proc/stat... > > > > > > And you can't even stick WARN into /proc/stat to find out. > > > > > > > FWIW, removing per irq counts from /proc/stat would break some of our > > scripts. We could adapt to that, but everybody else would have to as > > well, so I'm afraid it's not going to be possible. > > Excellent! > > > It would probably be better to extract out the stats that you're actually > > interested in to a new file. > > This is the worst scenario. Individual IRQ stats are going to live in 2 > places. > And /proc/stat still would be slow. No, a new /proc/stat2 which omits the `intr' line would be fast(er). Although if we're going to do such a thing we might choose to reorganize and prune /proc/stat2 even further, and actually put some thought into it - the current one is a bit of a dog's breakfast. Dumb question(s): a) if we moved the `intr' line to the very end of /proc/stat, would anything break? Maybe. b) if an application were then to read stuff from /proc/stat and were to stop reading before it read the `intr' line, would its read from /proc/stat still be slow? c) if the answer to b) is "yes" then can we change that? Only go off and prepare the `intr' line if the application is really truly reading it in?
