irq: remove not need bootmem code

use radix_tree irq_desc_tree instead of irq_desc_ptrs.

Signed-off-by Yinghai Lu <[email protected]>

---
 kernel/irq/handle.c |   47 ++++++++++++++++++++++-------------------------
 1 file changed, 22 insertions(+), 25 deletions(-)

Index: linux-2.6/kernel/irq/handle.c
===================================================================

kernel/irq/handle.c +9 -1

@@ -19,6 +19,7 @@
 #include <linux/kernel_stat.h>
 #include <linux/rculist.h>
 #include <linux/hash.h>
+#include <linux/radix-tree.h>
 #include <trace/events/irq.h>
 
 #include "internals.h"

@@ -127,7 +128,23 @@ static void init_one_irq_desc(int irq, s
  */
 DEFINE_RAW_SPINLOCK(sparse_irq_lock);
 
-static struct irq_desc **irq_desc_ptrs __read_mostly;
+static RADIX_TREE(irq_desc_tree, GFP_KERNEL);
+
+static void set_irq_desc(unsigned int irq, struct irq_desc *desc)
+{
+	radix_tree_insert(&irq_desc_tree, irq, desc);
+}
+
+struct irq_desc *irq_to_desc(unsigned int irq)

Quoted 43 lines · Yinghai Lu

use radix_tree irq_desc_tree instead of irq_desc_ptrs.

Signed-off-by Yinghai Lu <[email protected]>

---
 kernel/irq/handle.c |   47 ++++++++++++++++++++++-------------------------
 1 file changed, 22 insertions(+), 25 deletions(-)

Index: linux-2.6/kernel/irq/handle.c
===================================================================

kernel/irq/handle.c +18 -1

@@ -19,6 +19,7 @@
 #include <linux/kernel_stat.h>
 #include <linux/rculist.h>
 #include <linux/hash.h>
+#include <linux/radix-tree.h>
 #include <trace/events/irq.h>
 
 #include "internals.h"

@@ -127,7 +128,23 @@ static void init_one_irq_desc(int irq, s
  */
 DEFINE_RAW_SPINLOCK(sparse_irq_lock);
 
-static struct irq_desc **irq_desc_ptrs __read_mostly;
+static RADIX_TREE(irq_desc_tree, GFP_KERNEL);
+
+static void set_irq_desc(unsigned int irq, struct irq_desc *desc)
+{
+	radix_tree_insert(&irq_desc_tree, irq, desc);
+}
+
+struct irq_desc *irq_to_desc(unsigned int irq)
+{
+	return radix_tree_lookup(&irq_desc_tree, irq);
+}
+
+void replace_irq_desc(unsigned int irq, struct irq_desc *desc)
+{
+	radix_tree_delete(&irq_desc_tree, irq);
+	radix_tree_insert(&irq_desc_tree, irq, desc);
+}
 

...

Hi Yinghai,

should not we printk\warn if radix_tree_insert() is get failed? This is hardly (if ever) happen on machines with small number of interrupts allocated but anyway.

Or I miss something?

that is max number on run time.

Quoted 1 line · Yinghai Lu

that is max number on run time.

Ouch! Unless I misread this code this will leave nr_irqs at NR_IRQS_LEGACY. aka 16.

Let's do something stupid and simple.
nr_irqs = nr_cpus_ids * 256; /* Semi-arbitrary number */

Ideally we would set "nr_irqs = 0x7fffffff;" but we have just enough places using nr_irqs that I think those loops would get painful if we were to do that.

Quoted 7 lines · Eric W. Biederman

Quoted 1 line · Yinghai Lu

that is max number on run time.

Ouch!  Unless I misread this code this will leave nr_irqs at NR_IRQS_LEGACY. aka 16.

Quoted 2 lines

Let's do something stupid and simple.
nr_irqs = nr_cpus_ids * 256;  /* Semi-arbitrary number */

This would be 1048576 on the biggest machines we currently support. Now, the number of IRQ *vectors* is limited to
(224-system vectors)*(cpu count), so one could argue that if there is anything that is not semi-arbitrary it would be that number, but that doesn't account for vector sharing.

Do we have any place which requires nr_irqs to be *stable*, or can we simply treat it as a high water mark for IRQ numbers used?

Quoted 3 lines

Ideally we would set "nr_irqs = 0x7fffffff;" but we have just enough places using nr_irqs that I think those loops would get painful if we were to do that.

Ideally we should presumably get rid of nr_irqs completely?

Quoted 4 lines

Quoted 4 lines

Ouch! Unless I misread this code this will leave nr_irqs at NR_IRQS_LEGACY. aka 16.

Quoted 8 lines

Quoted 2 lines

Let's do something stupid and simple.
nr_irqs = nr_cpus_ids * 256; /* Semi-arbitrary number */

This would be 1048576 on the biggest machines we currently support. Now, the number of IRQ *vectors* is limited to
(224-system vectors)*(cpu count), so one could argue that if there is anything that is not semi-arbitrary it would be that number, but that doesn't account for vector sharing.

(256 - 32 - 16 - system_vectors) * cpu_count + 16

the 16 is legacy from IRQ0 to 15 has domain with all cpus set.

some interface in /proc/interrupts need it to make sure sth in sequence.

Quoted 6 lines · Eric W. Biederman

Quoted 1 line · Yinghai Lu

that is max number on run time.

Ouch! Unless I misread this code this will leave nr_irqs at NR_IRQS_LEGACY. aka 16.

Quoted 2 lines

Let's do something stupid and simple.
nr_irqs = nr_cpus_ids * 256; /* Semi-arbitrary number */

This would be 1048576 on the biggest machines we currently support. Now, the number of IRQ *vectors* is limited to
(224-system vectors)*(cpu count), so one could argue that if there is anything that is not semi-arbitrary it would be that number, but that doesn't account for vector sharing.

Do we have any place which requires nr_irqs to be *stable*, or can we simply treat it as a high water mark for IRQ numbers used?

Quoted 3 lines

Ideally we would set "nr_irqs = 0x7fffffff;" but we have just enough places using nr_irqs that I think those loops would get painful if we were to do that.

Ideally we should presumably get rid of nr_irqs completely?

I don't know if we ever actually perform vector sharing. The only case I recall where the code could share vectors is if the firmware tables told us to irq sources were the same interrupt. I don't think that happens. We do have the remains of support for vector sharing in the code but I don't think it is utilized. MSI interrupts certainly can not share vectors.

Yes. It was enough of a pain the first pass at it that we wound up with nr_irqs, a value that can vary at boot time.

Once YH's radix tree changes get it in. A war on NR_IRQS and nr_irqs seems appropriate.

Quoted 1 line · Yinghai Lu

that is max number on run time.

Ouch!  Unless I misread this code this will leave nr_irqs at NR_IRQS_LEGACY. aka 16.

Let's do something stupid and simple.
nr_irqs = nr_cpus_ids * 256;  /* Semi-arbitrary number */

Ideally we would set "nr_irqs = 0x7fffffff;" but we have just enough places using nr_irqs that I think those loops would get painful if we were to do that.

Quoted 6 lines · Eric W. Biederman

Quoted 1 line · Yinghai Lu

that is max number on run time.

Ouch!  Unless I misread this code this will leave nr_irqs at NR_IRQS_LEGACY. aka 16.

nr_irqs is set to NR_IRQS before.

Quoted 6 lines

Let's do something stupid and simple.
nr_irqs = nr_cpus_ids * 256;  /* Semi-arbitrary number */

Ideally we would set "nr_irqs = 0x7fffffff;" but we have just enough places using nr_irqs that I think those loops would get painful if we were to do that.

or you need have NR_IRQS = NR_CPUS * 256 at first,

and then make nr_irqs = nr_cpu_ids * 224 ?

Based on my quick look the bad offenders (aka static sized arrays of NR_IRQS) all look at NR_IRQS not nr_irqs.  So I don't see a point in having nr_irqs < NR_IRQS.

So let's just kill arch_probe_nr_irqs() on x86.

Then we can worry about things like fixing xen and the interrupt remapping code to not having NR_IRQS sized arrays.