linux-kernel - Re: [tip:x86/apic] x86/apic: Try to spread IRQ vectors to different priority levels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Jun 2012 14:41:11 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	mingo@...nel.org, agordeev@...hat.com,
	linux-kernel@...r.kernel.org, yinghai@...nel.org,
	tglx@...utronix.de, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/apic] x86/apic: Try to spread IRQ vectors to different
 priority levels

On Wed, 2012-06-20 at 10:23 -0700, H. Peter Anvin wrote:
> On 06/08/2012 07:50 AM, tip-bot for Alexander Gordeev wrote:
> > Commit-ID:  1bccd58bfffc5a677051937b332b71f0686187c1
> > Gitweb:     http://git.kernel.org/tip/1bccd58bfffc5a677051937b332b71f0686187c1
> > Author:     Alexander Gordeev <agordeev@...hat.com>
> > AuthorDate: Thu, 7 Jun 2012 15:15:15 +0200
> > Committer:  Ingo Molnar <mingo@...nel.org>
> > CommitDate: Fri, 8 Jun 2012 11:44:28 +0200
> > 
> > x86/apic: Try to spread IRQ vectors to different priority levels
> > 
> > When assigning a new vector it is primarially done by adding 8
> > to the previously given out vector number. Hence, two
> > consequently allocated vector numbers would likely fall into the
> > same priority level. Try to spread vector numbers to different
> > priority levels better by changing the step from 8 to 16.
> > 
> 
> OK, stupid question: WHY?
> 
> In general, in Linux the random prioritization is actually a negative.

Thinking loud in the context of your e-mail. With the relatively recent
changes like the commit mentioned below, window of higher priority class
preempting the lower priority class is minimized to the point at which
the cpu decides which interrupt to be serviced next. And in this case,
it doesn't matter if the two vectors are in two different priority
classes or the same class. Higher the vector number higher the priority
for the cpu to service next.

commit e58aa3d2d0cc01ad8d6f7f640a0670433f794922
Author: Ingo Molnar <mingo@...e.hu>
Date:   Fri Mar 26 00:06:51 2010 +0000

    genirq: Run irq handlers with interrupts disabled

> The only reason for the spreading by 8 is because of bugs/misfeatures in
> old APIC implementations which made them handle more than two interrupts
> per priority level rather inefficiently.

Peter, Is it just inefficiency or a functional bug in those old apic's?
Just wondering if it is just inefficiency and given the above linux
behavior does the inefficiency matter?

Anyways, these are old platforms that we probably don't want to mess
with. Perhaps we should go back to '8' and add a comment with all this
info, that the real intention is not to spread them across different
priority class but to avoid running into some old apic bugs.

thanks,
suresh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/