genirq, proc: Speedup /proc/stat interrupt statistics

Waiman reported that on large systems with a large amount of interrupts the readout of /proc/stat takes a long time to sum up the interrupt statistics. In principle this is not a problem. but for unknown reasons some enterprise quality software reads /proc/stat with a high frequency.

The reason for this is that interrupt statistics are accounted per cpu. So the /proc/stat logic has to sum up the interrupt stats for each interrupt.

This can be largely avoided for interrupts which are not marked as 'PER_CPU' interrupts by simply adding a per interrupt summation counter which is incremented along with the per interrupt per cpu counter.

The PER_CPU interrupts need to avoid that and use only per cpu accounting because they share the interrupt number and the interrupt descriptor and concurrent updates would conflict or require unwanted synchronization.

Reported-by Waiman Long <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

8<-------------

 include/linux/irqdesc.h |    3 ++-
 kernel/irq/chip.c       |   12 ++++++++++--
 kernel/irq/internals.h  |    8 +++++++-
 kernel/irq/irqdesc.c    |    7 ++++++-
 4 files changed, 25 insertions(+), 5 deletions(-)

include/linux/irqdesc.h +0 -0

@@ -65,9 +65,10 @@ struct irq_desc {
 	unsigned int		core_internal_state__do_not_mess_with_it;

Quoted 11 lines · Thomas Gleixner

include/linux/irqdesc.h +2 -1

@@ -65,9 +65,10 @@ struct irq_desc {
 	unsigned int		core_internal_state__do_not_mess_with_it;
 	unsigned int		depth;		/* nested irq disables */
 	unsigned int		wake_depth;	/* nested wake enables */
+	unsigned int		tot_count;
 	unsigned int		irq_count;	/* For detecting broken IRQs */
-	unsigned long		last_unhandled;	/* Aging timer for unhandled count */
 	unsigned int		irqs_unhandled;
+	unsigned long		last_unhandled;	/* Aging timer for unhandled count */

include/linux/irqdesc.h struct irq_desc { · line 74

Quoted 3 lines

include/linux/irqdesc.h +0 -0

 	atomic_t		threads_handled;
 	int			threads_handled_last;
 	raw_spinlock_t		lock;

Just one minor nit. Why you want to move the last_unhandled down one slot? There were 5 int's before. Adding one more will just fill the padding hole. Moving down the last_unhandled will probably leave 4-byte holes in both above and below it assuming that raw_spinlock_t is 4 bytes.

fs/proc/stat.c +13 -0

+static void show_irq_gap(struct seq_file *p, int gap)
+{
+	static const char zeros[] = " 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0";
+
+	while (gap > 0) {
+		int inc = min_t(int, gap, ARRAY_SIZE(zeros) / 2);
+
+		seq_write(p, zeros, 2 * inc);
+		gap -= inc;
+	}
+}
+
+static void show_all_irqs(struct seq_file *p)

Quoted 17 lines · Thomas Gleixner

fs/proc/stat.c +17 -0

+static void show_irq_gap(struct seq_file *p, int gap)
+{
+	static const char zeros[] = " 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0";
+
+	while (gap > 0) {
+		int inc = min_t(int, gap, ARRAY_SIZE(zeros) / 2);
+
+		seq_write(p, zeros, 2 * inc);
+		gap -= inc;
+	}
+}
+
+static void show_all_irqs(struct seq_file *p)
+{
+	int i, next = 0;
+
+	for_each_active_irq(i) {

fs/proc/stat.c static u64 get_iowait_time(int cpu) · line 104

Quoted 6 lines

fs/proc/stat.c +6 -0

+		show_irq_gap(p, i - next);
+		seq_put_decimal_ull(p, " ", kstat_irqs_usr(i));
+		next = i + 1;
+	}
+	show_irq_gap(p, nr_irqs - next);
+}

Every signed int can and should be unsigned int in this patch.

Waiman reported that on large systems with a large amount of interrupts the readout of /proc/stat takes a long time to sum up the interrupt statistics. In principle this is not a problem. but for unknown reasons some enterprise quality software reads /proc/stat with a high frequency.

The reason for this is that interrupt statistics are accounted per cpu. So the /proc/stat logic has to sum up the interrupt stats for each interrupt.

The following series addresses this by making the interrupt statitics code in the core generate the sum directly and by making the loop in the /proc/stat read function smarter.

Thanks,

tglx

8<----------------

 fs/proc/stat.c          |   28 +++++++++++++++++++++++++---
 include/linux/irqdesc.h |    3 ++-
 kernel/irq/chip.c       |   12 ++++++++++--
 kernel/irq/internals.h  |    8 +++++++-
 kernel/irq/irqdesc.c    |    7 ++++++-
 5 files changed, 50 insertions(+), 8 deletions(-)

Waiman reported that on large systems with a large amount of interrupts the readout of /proc/stat takes a long time to sum up the interrupt statistics. In principle this is not a problem. but for unknown reasons some enterprise quality software reads /proc/stat with a high frequency.

The reason for this is that interrupt statistics are accounted per cpu. So the /proc/stat logic has to sum up the interrupt stats for each interrupt.

The following series addresses this by making the interrupt statitics code in the core generate the sum directly and by making the loop in the /proc/stat read function smarter.

Quoted 8 lines · On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner <[email protected]> wrote:

Waiman reported that on large systems with a large amount of interrupts the readout of /proc/stat takes a long time to sum up the interrupt statistics. In principle this is not a problem. but for unknown reasons some enterprise quality software reads /proc/stat with a high frequency.

The reason for this is that interrupt statistics are accounted per cpu. So the /proc/stat logic has to sum up the interrupt stats for each interrupt.

Quoted 4 lines

The following series addresses this by making the interrupt statitics code in the core generate the sum directly and by making the loop in the /proc/stat read function smarter.

Has the speedup been quantified?

Quoted 10 lines · Andrew Morton

Quoted 8 lines · On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner <[email protected]> wrote:

Waiman reported that on large systems with a large amount of interrupts the readout of /proc/stat takes a long time to sum up the interrupt statistics. In principle this is not a problem. but for unknown reasons some enterprise quality software reads /proc/stat with a high frequency.

The reason for this is that interrupt statistics are accounted per cpu. So the /proc/stat logic has to sum up the interrupt stats for each interrupt.

Quoted 5 lines

Quoted 4 lines

The following series addresses this by making the interrupt statitics code in the core generate the sum directly and by making the loop in the /proc/stat read function smarter.

Has the speedup been quantified?

Waiman should be able to provide numbers

Quoted 10 lines · Andrew Morton

Quoted 8 lines · On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner <[email protected]> wrote:

Waiman reported that on large systems with a large amount of interrupts the readout of /proc/stat takes a long time to sum up the interrupt statistics. In principle this is not a problem. but for unknown reasons some enterprise quality software reads /proc/stat with a high frequency.

The reason for this is that interrupt statistics are accounted per cpu. So the /proc/stat logic has to sum up the interrupt stats for each interrupt.

Quoted 5 lines

Quoted 4 lines

The following series addresses this by making the interrupt statitics code in the core generate the sum directly and by making the loop in the /proc/stat read function smarter.

Has the speedup been quantified?

Waiman should be able to provide numbers