Messages in this thread | | | From | "Joel Fernandes (Google)" <> | Date | Thu, 19 Apr 2018 16:23:02 -0700 | Subject | Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs |
| |
Hi,
>>>> Or maintain array of registered irqs and iterate over them only. >>> Right, we can allocate a bitmap of used irqs to do that. >>> >>>> I have another idea. >>>> >>>> perf record shows mutex_lock/mutex_unlock at the top. >>>> Most of them are irq mutex not seqfile mutex as there are many more >>>> interrupts than reads. Take it once. >>>> >>> How many cpus are in your test system? In that skylake server, it was >>> the per-cpu summing operation of the irq counts that was consuming most >>> of the time for reading /proc/stat. I think we can certainly try to >>> optimize the lock taking. >> It's 16x(NR_IRQS: 4352, nr_irqs: 960, preallocated irqs: 16) >> Given that irq registering is rare operation, maintaining sorted array >> of irq should be the best option. >>> For the time being, I think I am going to have a clone /proc/stat2 as >>> suggested in my earlier email. Alternatively, I can put that somewhere >>> in sysfs if you have a good idea of where I can put it. >> sysfs is strictly one-value-per-file. >> >>> I will also look into ways to optimize the current per-IRQ stats >>> handling, but it will come later. >> There is always a time-honored way of ioctl(2) switching irq info off >> /proc supports that. >> >> There are many options. > > OK, it is good to know. Do you have any existing code snippet in the > kernel that I can use as reference on how to use ioctl(2) switching? > > I will look into how to optimize the existing per-IRQ stats code first > before venturing into cloning /proc/stat.
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 ?
thanks,
- Joel
| |