On 04/19/2018 03:08 PM, Alexey Dobriyan wrote: >> Therefore, application performance can be impacted if the application >> reads /proc/stat rather frequently. > [nods] > Text interfaces can be designed in a very stupid way. > >> For example, reading /proc/stat in a certain 2-socket Skylake server >> took about 4.6ms because it had over 5k irqs. > Is this top(1)? What is this application doing? > If it needs percpu usage stats, then maybe /proc/stat should be > converted away from single_open() so that core seq_file code doesn't > generate everything at once.
The application is actually a database benchmarking tool used by a customer. The reading of /proc/stat is an artifact of the benchmarking tool that can actually be turned off. Without doing that, about 20% of CPU time were spent reading /proc/stat and the trashing of cachelines slowed the benchmark number quite significantly. However, I was also told that there are legitimate cases where reading /proc/stat was necessary in some of their applications. >> - >> - /* sum again ? it could be updated? */ >> - for_each_irq_nr(j) >> - seq_put_decimal_ull(p, " ", kstat_irqs_usr(j)); >> - > This is direct userspace breakage. Yes, I am aware of that. That is the cost of improving the performance of applications that read /proc/stat, but don't need the individual irq counts. > > Proper fix is to start strategic switch away from /proc. > It is a fun toy but its time has come. Migration from procfs is easier said then done. Many existing customers are reluctant to do that. -Longman