All of lore.kernel.org
 help / color / mirror / Atom feed
From: jeremy.linton@arm.com (Jeremy Linton)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: mm: Prevent the initial page table setup from creating larger blocks
Date: Wed, 25 Nov 2015 10:31:48 -0600	[thread overview]
Message-ID: <5655E274.80103@arm.com> (raw)
In-Reply-To: <1448387338-27851-1-git-send-email-catalin.marinas@arm.com>

On 11/24/2015 11:48 AM, Catalin Marinas wrote:
> While the ARM ARM is not entirely clear, over the years we have assumed
> that we can split a large block entry (pmd/pud) into smaller blocks
> pointing to the same physical address with little risk of a TLB
> conflict. However, remapping a smaller blocks range as a large one (e.g.
> from page to sections or to contiguous pages) implies a high risk of TLB
> conflict. Excessive TLB flushing would make the window smaller but it
> would not remove the issue.

	Is a requirement of this assumption, that the kernel isn't running on a 
VM'ed host with small page mappings? AKA the hypervisor is providing 
smaller page sizes than guest linear mapping?

	Because I can understand the idea that the CPU won't walk PTEs for 
entries it has a larger translation for, but my understanding of how the 
TLB's are fragmented when the host has a smaller page size means that 
its potentially possible to have multiple TLB entries for different 
parts of a single cont/block range....

  reply	other threads:[~2015-11-25 16:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 17:48 [PATCH] arm64: mm: Prevent the initial page table setup from creating larger blocks Catalin Marinas
2015-11-25 16:31 ` Jeremy Linton [this message]
2015-11-25 18:08   ` Catalin Marinas
2015-11-25 22:58 ` Jeremy Linton
2015-11-26 16:06   ` Catalin Marinas

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=5655E274.80103@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.