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
| ||
|
Message-ID: <1330332354.11248.32.camel@twins> Date: Mon, 27 Feb 2012 09:45:54 +0100 From: Peter Zijlstra <peterz@...radead.org> To: Venki Pallipadi <venki@...gle.com> Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Suresh Siddha <suresh.b.siddha@...el.com>, Aaron Durbin <adurbin@...gle.com>, Paul Turner <pjt@...gle.com>, Yong Zhang <yong.zhang0@...il.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] Extend mwait idle to optimize away CAL and RES interrupts to an idle CPU -v1 On Thu, 2012-02-23 at 11:34 -0800, Venki Pallipadi wrote: > > > + local_bh_disable(); > > > + local_irq_disable(); > > > > That local_bh_disable() is completely superfluous, disabling IRQs > > already kills bh. > > The reason for local_bh_disable/enable was to check for potential > softirqs after these interrupt. Why is that needed? We never wrap local_irq_disable() in bh muck? > > Why doesn't ipiless_idle_exit() call this? That would keep it isolated > > to just those idle routines that actually use mwait instead of bothering > > the generic idle paths with this. > > ipiless_idle_exit is called in the inner most part of idle entry exit. > In mwait case we may not even have interrupts enabled at that time and > there is code that does idle residency timing etc which will get > impacted if we start doing the pending ipi work there. Doing it at > higher level along with things like enter-exit tickless felt nicer. But but but, an actual interrupt can be handled before the instruction after mwait, so why would this be a problem? -- 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/
Powered by blists - more mailing lists