linux-kernel - Re: [RFC] Extend mwait idle to optimize away IPIs when possible

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:	Fri, 10 Feb 2012 18:11:58 -0800
From:	Venki Pallipadi <venki@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
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>, linux-kernel@...r.kernel.org,
	Yong Zhang <yong.zhang0@...il.com>
Subject: Re: [RFC] Extend mwait idle to optimize away IPIs when possible

On Fri, Feb 10, 2012 at 11:19 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Mon, 2012-02-06 at 12:42 -0800, Venkatesh Pallipadi wrote:
>> smp_call_function_single and ttwu_queue_remote sends unconditional IPI
>> to target CPU. However, if the target CPU is in mwait based idle, we can
>> do IPI-less wakeups using the magical powers of monitor-mwait.
>
> So I was thinking, why not change native_smp_send_reschedule() and
> native_send_call_func_single_ipi() and keep the change entirely inside
> the arch?
>
> Ideally its only APIC/idle that know about this detail, the scheduler
> (or other consumers) really don't care about how the other cpu comes to
> run the callback.
>

OK. Moving most of this into arch code will be cleaner. But, Yong
mentioned in this thread that he was looking to do something similar
on MIPS. So, we may end up with some code duplication though..
--
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/