On 01/07/2019 11:33 AM, Alexey Dobriyan wrote: > On Mon, Jan 07, 2019 at 07:58:40AM -0800, Matthew Wilcox wrote: >> On Mon, Jan 07, 2019 at 10:12:58AM -0500, Waiman Long wrote: >>> A new "fs/proc-stat-irqs-latency-ms" sysctl parameter is now added to >> No. No, no, no, no, no. No. >> >> Stop adding new sysctls for this kind of thing. It's just a way to shift >> blame from us (who allegedly know what we're doing) to the sysadmin >> (who probably has better things to be doing than keeping up with the >> intricacies of development of every single piece of software running on >> their system). >> >> Let's figure out what this _should_ be. > Yeah, let's start interrogating about which values specifically this > super sekret applications wants. > > I assume CPU stats, so system call which returns CPU statistics in binary form. The /proc/stat file contains a bunch of statistics for different system parameters. I doubt the irq values are what most applications that read /proc/stats are looking for. The problem some customers see was the fact that they saw their application performance dropped quite significantly when moving to a newer system with more CPUs and more irqs. The issue here is their applications read /proc/stats at a relatively high frequency. The irq counting overhead can weight quite significantly and slow their applications down. Of course, they can modify their applications to try not to read /proc/stats that often. One instance where I was notified recently was the Oracle database that used lseek() to move the current file pointer of /proc/stats causing the system to recompute the stats every time the file pointer was moved. Of course, that is the not the right way to read a procfs file and they are probably going to change that. My point is customers are going to hit problem like that when they move to larger and newer systems. Thanks, Longman
