[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181107033234.djng6kas4tjkevln@linux-r8p5>
Date: Tue, 6 Nov 2018 19:32:34 -0800
From: Davidlohr Bueso <dave@...olabs.net>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Daniel Colascione <dancol@...gle.com>, longman@...hat.com,
linux-fsdevel@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH] fs/proc: introduce /proc/stat2 file
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
Powered by blists - more mailing lists