Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Dave Hansen wrote: > On 06/25/2015 04:48 AM, Ingo Molnar wrote: > > > I've updated the benchmarks with 4K flushes as well. Changes to the > > previous > > measurement: > > Did you push these out somewhere? The tip tmp.fpu branch hasn't seen any > updates. Not yet, I still don't trust

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Dave Hansen dave.han...@intel.com wrote: On 06/25/2015 04:48 AM, Ingo Molnar wrote: I've updated the benchmarks with 4K flushes as well. Changes to the previous measurement: Did you push these out somewhere? The tip tmp.fpu branch hasn't seen any updates. Not yet, I still

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Thu, Jun 25, 2015 at 12:15 PM, Vlastimil Babka wrote: >> [..] even aside from that, Intel seems to do particularly well at the >> "next page" TLB fill case > > AFAIK that's because they also cache partial translations, so if the first 3 > levels are the same (as they mostly are for the

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 25.6.2015 20:36, Linus Torvalds wrote: > > On Jun 25, 2015 04:48, "Ingo Molnar" > wrote: >> >> - 1x, 2x, 3x, 4x means up to 4 adjacent 4K vmalloc()-ed pages are accessed, >> the >>first byte in each > > So that test is a bit unfair. From previous timing of

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/25/2015 04:48 AM, Ingo Molnar wrote: > I've updated the benchmarks with 4K flushes as well. Changes to the previous > measurement: Did you push these out somewhere? The tip tmp.fpu branch hasn't seen any updates. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Kirill A. Shutemov wrote: > On Tue, Jun 09, 2015 at 08:34:35AM -0700, Dave Hansen wrote: > > On 06/09/2015 05:43 AM, Ingo Molnar wrote: > > > +static char tlb_flush_target[PAGE_SIZE] __aligned(4096); > > > +static void fn_flush_tlb_one(void) > > > +{ > > > + unsigned long addr = (unsigned

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Kirill A. Shutemov kir...@shutemov.name wrote: On Tue, Jun 09, 2015 at 08:34:35AM -0700, Dave Hansen wrote: On 06/09/2015 05:43 AM, Ingo Molnar wrote: +static char tlb_flush_target[PAGE_SIZE] __aligned(4096); +static void fn_flush_tlb_one(void) +{ + unsigned long addr =

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 25.6.2015 20:36, Linus Torvalds wrote: On Jun 25, 2015 04:48, Ingo Molnar mi...@kernel.org mailto:mi...@kernel.org wrote: - 1x, 2x, 3x, 4x means up to 4 adjacent 4K vmalloc()-ed pages are accessed, the first byte in each So that test is a bit unfair. From previous timing of

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/25/2015 04:48 AM, Ingo Molnar wrote: I've updated the benchmarks with 4K flushes as well. Changes to the previous measurement: Did you push these out somewhere? The tip tmp.fpu branch hasn't seen any updates. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Thu, Jun 25, 2015 at 12:15 PM, Vlastimil Babka vba...@suse.cz wrote: [..] even aside from that, Intel seems to do particularly well at the next page TLB fill case AFAIK that's because they also cache partial translations, so if the first 3 levels are the same (as they mostly are for the

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 08:34:35AM -0700, Dave Hansen wrote: > On 06/09/2015 05:43 AM, Ingo Molnar wrote: > > +static char tlb_flush_target[PAGE_SIZE] __aligned(4096); > > +static void fn_flush_tlb_one(void) > > +{ > > + unsigned long addr = (unsigned long)_flush_target; > > + > > +

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 08:34:35AM -0700, Dave Hansen wrote: On 06/09/2015 05:43 AM, Ingo Molnar wrote: +static char tlb_flush_target[PAGE_SIZE] __aligned(4096); +static void fn_flush_tlb_one(void) +{ + unsigned long addr = (unsigned long)tlb_flush_target; + +

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman wrote: > > > I made a really clear and unambiguous chain of arguments: > > > > > > - I'm unconvinced about the benefits of INVLPG in general, and your > > > patches adds > > >a whole new bunch of them. [...] > > > > ... and note that your claim that 'we were doing them

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman mgor...@suse.de wrote: I made a really clear and unambiguous chain of arguments: - I'm unconvinced about the benefits of INVLPG in general, and your patches adds a whole new bunch of them. [...] ... and note that your claim that 'we were doing them before,

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 12:42 PM, Linus Torvalds wrote: > On Wed, Jun 10, 2015 at 9:17 AM, Linus Torvalds > wrote: >> >> So anyway, I like the patch series. I just think that the final patch >> - the one that actually saves the addreses, and limits things to >> BATCH_TLBFLUSH_SIZE, should be

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 10:24 AM, Mel Gorman wrote: > > Yes, that was done earlier today based on Ingo's review so that the > allocation could be dealt with as a separate path at the end of the series. Ahh, ok, never mind then. > Ok, good point. Patch 3 in my git tree ("mm: Dynamically

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 09:42:34AM -0700, Linus Torvalds wrote: > On Wed, Jun 10, 2015 at 9:17 AM, Linus Torvalds > wrote: > > > > So anyway, I like the patch series. I just think that the final patch > > - the one that actually saves the addreses, and limits things to > > BATCH_TLBFLUSH_SIZE,

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 09:17:15AM -0700, Linus Torvalds wrote: > On Wed, Jun 10, 2015 at 6:13 AM, Andi Kleen wrote: > > > > Assuming the page tables are cache-hot... And hot here does not mean > > L3 cache, but higher. But a memory intensive workload can easily > > violate that. > > In

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 9:17 AM, Linus Torvalds wrote: > > So anyway, I like the patch series. I just think that the final patch > - the one that actually saves the addreses, and limits things to > BATCH_TLBFLUSH_SIZE, should be limited. Oh, and another thing: Mel, can you please make that

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 6:13 AM, Andi Kleen wrote: > > Assuming the page tables are cache-hot... And hot here does not mean > L3 cache, but higher. But a memory intensive workload can easily > violate that. In practice, no. You'll spend all your time on the actual real data cache misses, the

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 02:54:01PM -0700, Linus Torvalds wrote: > On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen wrote: > > > > The 0 cycle TLB miss was also interesting. It goes back up to something > > reasonable if I put the mb()/mfence's back. > > So I've said it before, and I'll say it again:

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 11:08:13AM +0200, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > Stop this crap. > > > > I made a really clear and unambiguous chain of arguments: > > > > - I'm unconvinced about the benefits of INVLPG in general, and your > > patches adds > >a whole new bunch

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 10:51:41AM +0200, Ingo Molnar wrote: > > * Mel Gorman wrote: > > > > I think since it is you who wants to introduce additional complexity into > > > the > > > x86 MM code the burden is on you to provide proof that the complexity of > > > pfn > > > (or struct page)

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Ingo Molnar wrote: > Stop this crap. > > I made a really clear and unambiguous chain of arguments: > > - I'm unconvinced about the benefits of INVLPG in general, and your patches > adds >a whole new bunch of them. [...] ... and note that your claim that 'we were doing them before,

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman wrote: > > I think since it is you who wants to introduce additional complexity into > > the > > x86 MM code the burden is on you to provide proof that the complexity of > > pfn > > (or struct page) tracking is worth it. > > I'm taking a situation whereby IPIs are sent like

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 11:08:13AM +0200, Ingo Molnar wrote: * Ingo Molnar mi...@kernel.org wrote: Stop this crap. I made a really clear and unambiguous chain of arguments: - I'm unconvinced about the benefits of INVLPG in general, and your patches adds a whole new bunch

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 10:51:41AM +0200, Ingo Molnar wrote: * Mel Gorman mgor...@suse.de wrote: I think since it is you who wants to introduce additional complexity into the x86 MM code the burden is on you to provide proof that the complexity of pfn (or struct page)

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 02:54:01PM -0700, Linus Torvalds wrote: On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen dave.han...@intel.com wrote: The 0 cycle TLB miss was also interesting. It goes back up to something reasonable if I put the mb()/mfence's back. So I've said it before, and I'll

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman mgor...@suse.de wrote: I think since it is you who wants to introduce additional complexity into the x86 MM code the burden is on you to provide proof that the complexity of pfn (or struct page) tracking is worth it. I'm taking a situation whereby IPIs are sent like

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Ingo Molnar mi...@kernel.org wrote: Stop this crap. I made a really clear and unambiguous chain of arguments: - I'm unconvinced about the benefits of INVLPG in general, and your patches adds a whole new bunch of them. [...] ... and note that your claim that 'we were doing them

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 6:13 AM, Andi Kleen a...@firstfloor.org wrote: Assuming the page tables are cache-hot... And hot here does not mean L3 cache, but higher. But a memory intensive workload can easily violate that. In practice, no. You'll spend all your time on the actual real data cache

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 9:17 AM, Linus Torvalds torva...@linux-foundation.org wrote: So anyway, I like the patch series. I just think that the final patch - the one that actually saves the addreses, and limits things to BATCH_TLBFLUSH_SIZE, should be limited. Oh, and another thing: Mel, can

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 09:42:34AM -0700, Linus Torvalds wrote: On Wed, Jun 10, 2015 at 9:17 AM, Linus Torvalds torva...@linux-foundation.org wrote: So anyway, I like the patch series. I just think that the final patch - the one that actually saves the addreses, and limits things to

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 12:42 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Jun 10, 2015 at 9:17 AM, Linus Torvalds torva...@linux-foundation.org wrote: So anyway, I like the patch series. I just think that the final patch - the one that actually saves the addreses, and

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 10:24 AM, Mel Gorman mgor...@suse.de wrote: Yes, that was done earlier today based on Ingo's review so that the allocation could be dealt with as a separate path at the end of the series. Ahh, ok, never mind then. Ok, good point. Patch 3 in my git tree (mm:

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Wed, Jun 10, 2015 at 09:17:15AM -0700, Linus Torvalds wrote: On Wed, Jun 10, 2015 at 6:13 AM, Andi Kleen a...@firstfloor.org wrote: Assuming the page tables are cache-hot... And hot here does not mean L3 cache, but higher. But a memory intensive workload can easily violate that. In

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 11:32:03PM +0100, Mel Gorman wrote: > On Tue, Jun 09, 2015 at 02:54:01PM -0700, Linus Torvalds wrote: > > On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen wrote: > > > > > > The 0 cycle TLB miss was also interesting. It goes back up to something > > > reasonable if I put the

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 02:54:01PM -0700, Linus Torvalds wrote: > On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen wrote: > > > > The 0 cycle TLB miss was also interesting. It goes back up to something > > reasonable if I put the mb()/mfence's back. > > So I've said it before, and I'll say it again:

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen wrote: > > The 0 cycle TLB miss was also interesting. It goes back up to something > reasonable if I put the mb()/mfence's back. So I've said it before, and I'll say it again: Intel does really well on TLB fills. The reason is partly historical, with

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

I did some of what I talked about earlier in the thread. I think the sfence (via mb()) is potentially unfair since it removes some of the CPU's ability to optimize things. For this kind of test, any ability that the CPU has to smear the overhead around is a bonus in practice and should be taken

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/09/2015 08:34 AM, Dave Hansen wrote: > 2. We should measure flushing of ascending, adjacent virtual addresses >mapped with 4k pages since that is the normal case. Perhaps >vmalloc(16MB) or something. Now that I think about this a bit more, we really have two different patterns

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/09/2015 05:43 AM, Ingo Molnar wrote: > I cited very real numbers about the direct costs of TLB flushes, and > plausible > speculation about why the indirect costs are low on the achitecture you are > trying > to modify here. We should be careful to extrapolate what the real-world cost

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 02:43:28PM +0200, Ingo Molnar wrote: > > * Mel Gorman wrote: > > > > Sorry, I don't buy this, at all. > > > > > > Please measure this, the code would become a lot simpler, as I'm not > > > convinced > > > that we need pfn (or struct page) or even range based flushing.

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman wrote: > > Sorry, I don't buy this, at all. > > > > Please measure this, the code would become a lot simpler, as I'm not > > convinced > > that we need pfn (or struct page) or even range based flushing. > > The code will be simplier and the cost of reclaim will be lower and

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 12:32:31PM +0200, Ingo Molnar wrote: > > * Mel Gorman wrote: > > > > So have you explored the possibility to significantly simplify your > > > patch-set > > > by only deferring the flushing, and doing a simple TLB flush on the > > > remote > > > CPU? > > > > Yes. At

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman wrote: > > So have you explored the possibility to significantly simplify your > > patch-set > > by only deferring the flushing, and doing a simple TLB flush on the remote > > CPU? > > Yes. At one point I looked at range flushing but it is not a good idea. My suggestion wasn't

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Mon, Jun 08, 2015 at 07:45:51PM +0200, Ingo Molnar wrote: > > * Mel Gorman wrote: > > > Changelog since V4 > > o Rebase to 4.1-rc6 > > > > Changelog since V3 > > o Drop batching of TLB flush from migration > > o Redo how larger batching is managed > > o Batch TLB flushes when writable

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Mon, Jun 08, 2015 at 07:45:51PM +0200, Ingo Molnar wrote: * Mel Gorman mgor...@suse.de wrote: Changelog since V4 o Rebase to 4.1-rc6 Changelog since V3 o Drop batching of TLB flush from migration o Redo how larger batching is managed o Batch TLB flushes when writable entries

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman mgor...@suse.de wrote: So have you explored the possibility to significantly simplify your patch-set by only deferring the flushing, and doing a simple TLB flush on the remote CPU? Yes. At one point I looked at range flushing but it is not a good idea. My suggestion

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 12:32:31PM +0200, Ingo Molnar wrote: * Mel Gorman mgor...@suse.de wrote: So have you explored the possibility to significantly simplify your patch-set by only deferring the flushing, and doing a simple TLB flush on the remote CPU? Yes. At one

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/09/2015 05:43 AM, Ingo Molnar wrote: I cited very real numbers about the direct costs of TLB flushes, and plausible speculation about why the indirect costs are low on the achitecture you are trying to modify here. We should be careful to extrapolate what the real-world cost of a

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/09/2015 08:34 AM, Dave Hansen wrote: 2. We should measure flushing of ascending, adjacent virtual addresses mapped with 4k pages since that is the normal case. Perhaps vmalloc(16MB) or something. Now that I think about this a bit more, we really have two different patterns here:

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

I did some of what I talked about earlier in the thread. I think the sfence (via mb()) is potentially unfair since it removes some of the CPU's ability to optimize things. For this kind of test, any ability that the CPU has to smear the overhead around is a bonus in practice and should be taken

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 02:54:01PM -0700, Linus Torvalds wrote: On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen dave.han...@intel.com wrote: The 0 cycle TLB miss was also interesting. It goes back up to something reasonable if I put the mb()/mfence's back. So I've said it before, and I'll

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 11:32:03PM +0100, Mel Gorman wrote: On Tue, Jun 09, 2015 at 02:54:01PM -0700, Linus Torvalds wrote: On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen dave.han...@intel.com wrote: The 0 cycle TLB miss was also interesting. It goes back up to something reasonable if I

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen dave.han...@intel.com wrote: The 0 cycle TLB miss was also interesting. It goes back up to something reasonable if I put the mb()/mfence's back. So I've said it before, and I'll say it again: Intel does really well on TLB fills. The reason is

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman mgor...@suse.de wrote: Sorry, I don't buy this, at all. Please measure this, the code would become a lot simpler, as I'm not convinced that we need pfn (or struct page) or even range based flushing. The code will be simplier and the cost of reclaim will be lower and

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On Tue, Jun 09, 2015 at 02:43:28PM +0200, Ingo Molnar wrote: * Mel Gorman mgor...@suse.de wrote: Sorry, I don't buy this, at all. Please measure this, the code would become a lot simpler, as I'm not convinced that we need pfn (or struct page) or even range based flushing.

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Dave Hansen wrote: > On 06/08/2015 12:52 PM, Ingo Molnar wrote: > > A CR3 driven TLB flush takes less time than a single INVLPG (!): > > > >[0.389028] x86/fpu: Cost of: __flush_tlb() fn > > :96 cycles > >[0.405885] x86/fpu: Cost of:

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/08/2015 12:52 PM, Ingo Molnar wrote: > A CR3 driven TLB flush takes less time than a single INVLPG (!): > >[0.389028] x86/fpu: Cost of: __flush_tlb() fn > :96 cycles >[0.405885] x86/fpu: Cost of: __flush_tlb_one() fn > :

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Ingo Molnar wrote: > So what I measured agrees generally with the comment you added in the commit: > > + * Each single flush is about 100 ns, so this caps the maximum overhead at > + * _about_ 3,000 ns. > > Let that sink through: 3,000 nsecs = 3 usecs, that's like eternity! > > A CR3

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Dave Hansen wrote: > On 06/08/2015 10:45 AM, Ingo Molnar wrote: > > As per my measurements the __flush_tlb_single() primitive (which you use in > > patch > > #2) is very expensive on most Intel and AMD CPUs. It barely makes sense for > > a 2 > > pages and gets exponentially worse. It's

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/08/2015 10:45 AM, Ingo Molnar wrote: > As per my measurements the __flush_tlb_single() primitive (which you use in > patch > #2) is very expensive on most Intel and AMD CPUs. It barely makes sense for a > 2 > pages and gets exponentially worse. It's probably done in microcode and its >

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman wrote: > Changelog since V4 > o Rebase to 4.1-rc6 > > Changelog since V3 > o Drop batching of TLB flush from migration > o Redo how larger batching is managed > o Batch TLB flushes when writable entries exist > > When unmapping pages it is necessary to flush the TLB. If that page

[PATCH 0/3] TLB flush multiple pages per IPI v5

Changelog since V4 o Rebase to 4.1-rc6 Changelog since V3 o Drop batching of TLB flush from migration o Redo how larger batching is managed o Batch TLB flushes when writable entries exist When unmapping pages it is necessary to flush the TLB. If that page was accessed by another CPU then an IPI

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/08/2015 10:45 AM, Ingo Molnar wrote: As per my measurements the __flush_tlb_single() primitive (which you use in patch #2) is very expensive on most Intel and AMD CPUs. It barely makes sense for a 2 pages and gets exponentially worse. It's probably done in microcode and its

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Ingo Molnar mi...@kernel.org wrote: So what I measured agrees generally with the comment you added in the commit: + * Each single flush is about 100 ns, so this caps the maximum overhead at + * _about_ 3,000 ns. Let that sink through: 3,000 nsecs = 3 usecs, that's like eternity! A

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Dave Hansen dave.han...@intel.com wrote: On 06/08/2015 10:45 AM, Ingo Molnar wrote: As per my measurements the __flush_tlb_single() primitive (which you use in patch #2) is very expensive on most Intel and AMD CPUs. It barely makes sense for a 2 pages and gets exponentially worse.

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Mel Gorman mgor...@suse.de wrote: Changelog since V4 o Rebase to 4.1-rc6 Changelog since V3 o Drop batching of TLB flush from migration o Redo how larger batching is managed o Batch TLB flushes when writable entries exist When unmapping pages it is necessary to flush the TLB. If

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

On 06/08/2015 12:52 PM, Ingo Molnar wrote: A CR3 driven TLB flush takes less time than a single INVLPG (!): [0.389028] x86/fpu: Cost of: __flush_tlb() fn :96 cycles [0.405885] x86/fpu: Cost of: __flush_tlb_one() fn : 260

Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Dave Hansen dave.han...@intel.com wrote: On 06/08/2015 12:52 PM, Ingo Molnar wrote: A CR3 driven TLB flush takes less time than a single INVLPG (!): [0.389028] x86/fpu: Cost of: __flush_tlb() fn :96 cycles [0.405885] x86/fpu: Cost of:

[PATCH 0/3] TLB flush multiple pages per IPI v5

Changelog since V4 o Rebase to 4.1-rc6 Changelog since V3 o Drop batching of TLB flush from migration o Redo how larger batching is managed o Batch TLB flushes when writable entries exist When unmapping pages it is necessary to flush the TLB. If that page was accessed by another CPU then an IPI