[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55400CA7.3050902@redhat.com>
Date: Tue, 28 Apr 2015 18:41:43 -0400
From: Rik van Riel <riel@...hat.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>,
Andy Lutomirski <luto@...capital.net>,
Dave Hansen <dave.hansen@...el.com>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...e.de>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, x86@...nel.org
Subject: Re: PCID and TLB flushes (was: [GIT PULL] kdbus for 4.1-rc1)
On 04/28/2015 06:15 PM, Kirill A. Shutemov wrote:
> On Tue, Apr 28, 2015 at 01:42:10PM -0700, Andy Lutomirski wrote:
>> At some point, I'd like to implement PCID on x86 (if no one beats me
>> to it, and this is a low priority for me), which will allow us to skip
>> expensive TLB flushes while context switching. I have no idea whether
>> ARM can do something similar.
>
> I talked with Dave about implementing PCID and he thinks that it will be
> net loss. TLB entries will live longer and it means we would need to trigger
> more IPIs to flash them out when we have to. Cost of IPIs will be higher
> than benifit from hot TLB after context switch.
I suspect that may depend on how you do the shootdown.
If, when receiving a TLB shootdown for a non-current PCID, we just flush
all the entries for that PCID and remove the CPU from the mm's
cpu_vm_mask_var, we will never receive more than one shootdown IPI for
a non-current mm, but we will still get the benefits of TLB longevity
when dealing with eg. pipe workloads where tasks take turns running on
the same CPU.
--
All rights reversed
--
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