From: Bob Picco <bob.picco@xxxxxxxxxx> Date: Tue, 9 Sep 2014 15:34:24 -0400 > David Miller wrote: [Tue Sep 09 2014, 03:17:52PM EDT] >> From: Bob Picco <bpicco@xxxxxxxxxx> >> Date: Sun, 7 Sep 2014 11:45:07 -0400 >> >> > From: bob picco <bpicco@xxxxxxxxxx> >> > >> > This patch attempts to do a few things. The highlights are: 1) provides the >> > option to enable SPARSE_IRQ, 2) allocates ivector_table at boot time and >> > 3) default to cookie only VIRQ mechanism for supported firmware. The >> > first firmware with cookie only support for me appears on T5. You can >> > optionally force the HV firmware to not cookie only mode which is the >> > sysino support. >> > >> > The sysino is a deprecated HV mechanism according to the most recent >> > SPARC Virtual Machine Specification. HV_GRP_INTR is what controls the >> > cookie/sysino firmware versioning. The history appears to be something like >> > this: >> > major version 2 was dropped. >> > major version 3 is where a cookie only VIRQ >> > is possible. Using version 3 means ivector_table isn't required. >> > >> > A new boot option is provided should cookie only HV support have issues. >> > hvirq - this is the version for HV_GRP_INTR. This is related to HV API >> > versioning. The code attempts major=3 first by default. The option can >> > be used to override this default. >> > >> > I've tested with SPARSE_IRQ on T5-8, M7-4 and T4-X and Ultra 45. I've also >> > tested Ultra45 (Jalap?no) with !SPARSE_IRQ. >> > >> > Cc: sparclinux@xxxxxxxxxxxxxxx >> > Signed-off-by: Bob Picco <bob.picco@xxxxxxxxxx> >> >> Let's just bite the bullet and enable SPARSE_IRQ unconditionally >> on SPARC64. > Okay. Do you require more from me? I only require that you respin this patch to unconditionally enable SPARSE_IRQ. Well, now that you are asking I do have a few more points I'm interested in :-) In irq_alloc() you can probably just use irq_alloc_desc(), is IRQ 0 really special in some way that we cannot allocate it? That's the only reason I see for using __irq_alloc_descs(). Also, please use NUMA_NO_NODE for the node argument rather than -1. I am assuming that at some point you will perhaps add some logic to pick a specific node if appropriate. Also, once you go to using SPARSE_IRQ always there is absolutely no reason to pick one NR_IRQS value over another. I would suggest therefore that you use the maximum possible value which, reading your patch, seems to be something like 8192. If you still want the conditional NR_IRQS sizing in there, I want to see more details about what exactly determines the size you want to use. It's based upon NR_CPUS now but I can't understand that. What matters is how many virtual or real devices having INOs exist in the machine, and that seems like a purely platform property to me. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
