linux-kernel - Re: [PATCH v7 8/8] x86/tlb: just do tlb flush on one of siblings of SMT

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: <CAObL_7FK8Pb7Ahmr0SBaPg1BvPTspr=EKG8v_QfcpdmMyuE5dA@mail.gmail.com>
Date:	Thu, 24 May 2012 06:19:21 -0700
From:	Andrew Lutomirski <luto@....edu>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Jan Beulich <JBeulich@...e.com>, Alex Shi <alex.shi@...el.com>,
	borislav.petkov@....com, arnd@...db.de, akinobu.mita@...il.com,
	eric.dumazet@...il.com, fweisbec@...il.com, rostedt@...dmis.org,
	hughd@...gle.com, jeremy@...p.org, len.brown@...el.com,
	tony.luck@...el.com, yongjie.ren@...el.com,
	kamezawa.hiroyu@...fujitsu.com, seto.hidetoshi@...fujitsu.com,
	penberg@...nel.org, yinghai@...nel.org, tglx@...utronix.de,
	akpm@...ux-foundation.org, ak@...ux.intel.com, avi@...hat.com,
	dhowells@...hat.com, mingo@...hat.com, riel@...hat.com,
	cpw@....com, steiner@....com, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, hpa@...or.com
Subject: Re: [PATCH v7 8/8] x86/tlb: just do tlb flush on one of siblings of SMT

On Thu, May 24, 2012 at 12:40 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, 2012-05-23 at 18:46 -0700, Andrew Lutomirski wrote:
>> On Wed, May 23, 2012 at 10:15 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>> > On Wed, 2012-05-23 at 19:09 +0200, Peter Zijlstra wrote:
>> >> > There is no comment or anything else indicating that this is
>> >> > suitable for dual-thread CPUs only - when there are more than
>> >> > 2 threads per core, the intended effect won't be achieved.
>> >>
>> >> Why would that be? Won't higher thread count still share the same
>> >> resources just more so?
>> >
>> > Ah, I see, you're saying his code is buggy for >2 threads. Agreed.
>> >
>>
>> An evil knob to statically choose which SMT sibling gets the interrupt
>> would be nice.  Then my compute-intensive thread could be (mostly)
>> unaffected by the other thread on a different core that calls munmap
>> frequently.
>
> Just make sure the two workloads never share a core and this should
> already happen since TLB invalidates are only broadcast to the mm
> cpumask.
>

I already do that.  But these two workloads share the same mm (they're
threads in the same process), so I'd gain performance if the
invalidations were sent from the core that called munmap to the SMT
sibling of the other thread.

A decent heuristic might be to prefer idle SMT siblings for TLB
invalidation.  I don't know what effect that would have on power
consumption (it would be rather bad if idling one SMT thread while the
other one is busy saves much power).

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