On 11/06/2018 10:32 PM, Davidlohr Bueso wrote: > 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. > In my case, the customers just complain about the slowdown in reading /proc/stat on some platforms vs. the others because some had many more interrupt lines than the others. They didn't specifically call out what they were looking at. >> >> 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 Yes, the time spent will scale more or less linearly with the # of cores and # of interrupts. Thanks, Longman
