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

[Andrew Lutomirski]

On Thu, May 24, 2012 at 12:40 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/