Messages in this thread | | | Date | Tue, 16 Jul 2019 12:07:45 -0400 | From | Neil Horman <> | Subject | Re: [PATCH] x86: Add irq spillover warning |
| |
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 >
| |