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: <4FBE39FE.4050001@linux.intel.com>
Date:	Thu, 24 May 2012 06:39:10 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Andrew Lutomirski <luto@....edu>, 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 5/24/2012 6:23 AM, Peter Zijlstra wrote:
> On Thu, 2012-05-24 at 06:19 -0700, Andrew Lutomirski wrote:
>>
>> 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). 

we really really shouldn't do flushing of tlb's on only one half of SMT.
SMT sibblings have their own TLB pool at least on some of Intels chips.

Also, note that on anything sane, we flush the tlb's in software before
going to an Idle state, so that we don't have to wake idle cpus up to
flush their TLBs (except for "global tlbs", but those change very very
very rarely hopefully)

> 
> Right, I've never really understood how C-states and SMT go together.
> Arjan recently implied waking a thread sibling from C-state was
> 'expensive' which on first thought seems daft, the core is running
> already.

in order to wake *anything* you need to send an IPI to it, it has to
exit the idle loop etc etc. It's not expensive-expensive, but it
certainly is not free either.
--
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/