On Tue, Jul 16, 2019 at 05:57:31PM +0200, Thomas Gleixner wrote: > Neil, > > On Tue, 16 Jul 2019, Neil Horman wrote: > > > On Intel hardware, cpus are limited in the number of irqs they can > > have affined to them (currently 240), based on section 10.5.2 of: > > https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf > > That reference is really not useful to explain the problem and the number > of vectors is neither. Please explain the conceptual issue. > You seem to have already done that below. Not really sure what more you are asking for here.
> > If a cpu has more than this number of interrupts affined to it, they > > will spill over to other cpus, which potentially may be outside of their > > affinity mask. > > Spill over? > > The kernel decides to pick a vector on a CPU outside of the affinity when > it runs out of vectors on the CPUs in the affinity mask. > Yes. > Please explain issues technically correct. > I don't know what you mean by this. I explained it above, and you clearly understood it. > > Given that this might cause unexpected behavior on > > performance sensitive systems, warn the user should this condition occur > > so that corrective action can be taken > > > @@ -244,6 +244,14 @@ __visible unsigned int __irq_entry do_IRQ(struct > > pt_regs *regs) > > Why on earth warn in the interrupt delivery hotpath? Just because it's the > place which really needs extra instructions and extra cache lines on > performance sensitive systems, right? > Because theres already a check of the same variety in do_IRQ, but if the information is available outside the hotpath, I was unaware, and am happy to update this patch to refelct that. > The fact that the kernel ran out of vectors for the CPUs in the affinity > mask is already known when the vector is allocated in activate_reserved(). > > So there is an obvious place to put such a warning and it's certainly not > do_IRQ(). > Sure Thanks Neil > Thanks, > > tglx >