linux-kernel - Re: Reworking suspend-resume sequence (was: Re: PCI PM: Restore standard config registers of all devices early)

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]

Message-ID: <20090203210442.GA27804@elte.hu>
Date:	Tue, 3 Feb 2009 22:04:42 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Jesse Barnes <jesse.barnes@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andreas Schwab <schwab@...e.de>, Len Brown <lenb@...nel.org>
Subject: Re: Reworking suspend-resume sequence (was: Re: PCI PM: Restore
	standard config registers of all devices early)

* Ingo Molnar <mingo@...e.hu> wrote:

[...]
> That principle works both for networking and for other IO transports - but 
> we have little support for it yet. It would work really well for workloads 
> where one physical device is shared by many CPUs.

Which is really what we have in _practice_ - only benchmarketing sets up one 
physical device per CPU and avoids all the ugly consequences of 
gathering/spreadig a channel of information from/to a single device to 
multiple CPUs.

> (A lesser method that approximates this is the use of lots of 
> submission/completion rings per device and their binding to cpus - but 
> that can never really approach the number of CPUs really possible in a 
> system.)

btw., more advanced device IRQ models was one of the thinking behind sparse 
IRQ support: defining a really large NR_IRQS limit on x86 by default, on all 
form factors, and making it really easy and cheap to have a _ton_ of IRQs in 
a Linux system might give hw designers ideas to create such hardware.

/me dreams on ;-)

> And in this most advanced mode of MSI IRQs, and if MSI devices had the 
> ability to direct IRQs to a specific CPU (they dont have that right now 
> AFAICT), we'd run into the overhead scenarios you describe above, and your 
> edge-triggered flow is the most performant one.

So i'd still like your tentative Signed-off-by for your patch - it's i think 
not v2.6.29 material but if it stays problem free in testing we can try it 
in v2.6.30. If it causes problem it will be clearly bisectable and clearly 
revertable.

Maybe we could split it in two: and for MSI we could introduce a 'simpler 
and faster' edge flow as well - and keep the legacy handler untouched. That 
way it's low-risk in its entirety. (and avoids the MSI ->mask complication 
as well.)

	Ingo
--
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/