linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: David Rientjes <rientjes@google.com>,
	linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [PATCH] mm: Flush the TLB for a single address in a huge page
Date: Thu, 23 Jul 2015 11:49:38 +0100	[thread overview]
Message-ID: <20150723104938.GA27052@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <55B021B1.5020409@intel.com>

On Thu, Jul 23, 2015 at 12:05:21AM +0100, Dave Hansen wrote:
> On 07/22/2015 03:48 PM, Catalin Marinas wrote:
> > You are right, on x86 the tlb_single_page_flush_ceiling seems to be
> > 33, so for an HPAGE_SIZE range the code does a local_flush_tlb()
> > always. I would say a single page TLB flush is more efficient than a
> > whole TLB flush but I'm not familiar enough with x86.
> 
> The last time I looked, the instruction to invalidate a single page is
> more expensive than the instruction to flush the entire TLB. 

I was thinking of the overall cost of re-populating the TLB after being
nuked rather than the instruction itself.

> We also don't bother doing ranged flushes _ever_ for hugetlbfs TLB
> invalidations, but that was just because the work done around commit
> e7b52ffd4 didn't see any benefit.

For huge pages, there are indeed fewer page table levels to fetch, so I
guess the impact is not significant. With virtualisation/nested pages,
at least on ARM, refilling the TLB for guest would take longer (though
it's highly dependent on the microarchitecture implementation, whether
it caches the guest PA to host PA separately).

> That said, I can't imagine this will hurt anything.  We also have TLBs
> that can mix 2M and 4k pages and I don't think we did back when we put
> that code in originally.

Another question is whether flushing a single address is enough for a
huge page. I assumed it is since tlb_remove_pmd_tlb_entry() only adjusts
the mmu_gather range by PAGE_SIZE (rather than HPAGE_SIZE) and no-one
complained so far. AFAICT, there are only 3 architectures that don't use
asm-generic/tlb.h but they all seem to handle this case:

arch/arm: it implements tlb_remove_pmd_tlb_entry() in a similar way to
the generic one

arch/s390: tlb_remove_pmd_tlb_entry() is a no-op

arch/ia64: does not support THP

-- 
Catalin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2015-07-23 10:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 17:13 [PATCH] mm: Flush the TLB for a single address in a huge page Catalin Marinas
2015-07-22 21:39 ` David Rientjes
2015-07-22 22:48   ` Catalin Marinas
2015-07-22 23:05     ` Dave Hansen
2015-07-23 10:49       ` Catalin Marinas [this message]
2015-07-23 14:13         ` Andrea Arcangeli
2015-07-23 14:41           ` Dave Hansen
2015-07-23 15:58             ` Andrea Arcangeli
2015-07-23 16:52               ` Dave Hansen
2015-07-23 16:16             ` Catalin Marinas
2015-07-23 16:55               ` Dave Hansen
2015-07-23 17:13                 ` Andrea Arcangeli
2015-07-23 16:49           ` Catalin Marinas
2015-07-24  7:17             ` Martin Schwidefsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150723104938.GA27052@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).