On Thu, Sep 8, 2016 at 6:00 PM, Randy Dunlap <[email protected]> wrote: > On 09/08/16 13:25, Craig Gallek wrote: >> From: Craig Gallek <[email protected]> >> >> Add struct kobject to struct irq_desc to allow for easy export >> to sysfs. This allows for much simpler userspace-parsing of >> the information contained in struct irq_desc. >> >> Note that sysfs is not available at the time of early irq initialization. >> These interrupts are accounted for using a postcore_initcall callback. >> >> Examples: >> /sys/kernel/irq/18/actions: i801_smbus,ehci_hcd:usb1,uhci_hcd:usb7 >> /sys/kernel/irq/18/chip_name: IR-IO-APIC >> /sys/kernel/irq/18/hwirq: 18 >> /sys/kernel/irq/18/name: fasteoi >> /sys/kernel/irq/18/per_cpu_count: 0,0 >> /sys/kernel/irq/18/type: level >> >> /sys/kernel/irq/25/actions: ahci0 >> /sys/kernel/irq/25/chip_name: IR-PCI-MSI >> /sys/kernel/irq/25/hwirq: 512000 >> /sys/kernel/irq/25/name: edge >> /sys/kernel/irq/25/per_cpu_count: 29036,0 >> /sys/kernel/irq/25/type: edge > > Thanks for the update. > > One concern: > > This per_cpu_count is for online CPUs only. > How does this help when the online CPUs change? > > E.g., above could be for CPUs 1 and 5. > The next time that it is read it could be for CPUs 0 and 3. > Seems that it could be confusing even for software reading it.
Thanks for the feedback. I imagine most use cases for this will simply add up all the values to obtain a total. There's not a lot of use for the individual elements unless you additionally know something about the CPU id layout, interrupt pinning, and/or CPU online state. The /proc/interrupts interface has this same issue, but additionally uses column headers. There's really know way to give a similar consistent view of all of this data using multiple sysfs files. Given this lack of atomicity, across files, I don't think it's unreasonable for the counter order to change when the system's online CPUs change. The only alternative I could imagine would be to include a header row in this file listing the CPU ids as a parallel list. I think this goes against the standard sysfs file format, though...
