From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Lutomirski <luto@kernel.org>
Cc: Nadav Amit <nadav.amit@gmail.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
X86 ML <x86@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mel Gorman <mgorman@suse.de>,
Peter Zijlstra <peterz@infradead.org>,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH v2 00/10] PCID and improved laziness
Date: Thu, 15 Jun 2017 07:58:18 +0900 [thread overview]
Message-ID: <CA+55aFyN_iA4CwVdEvwv4bWu1Y-ihsYcskcCD93=DGahown7sQ@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFxzXmg3Kkk+NaXYFy4JsQpbUcZ+CGTgTqAdOsOGqA_E_Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 990 bytes --]
On Jun 15, 2017 7:48 AM, "Andy Lutomirski" <luto@kernel.org> wrote:
Then throw EPT into the mix for extra fun. I wonder if we should try
to allocate page tables from nearby physical addresses if we think we
might be running as a guest.
They are already dense in the cache in the last level, and upper levels are
already fairly dense if you are just *reasonably* dense in your virtual
mapping.
Yes, for virtualization, the "virtual mapping" ends up being those page
tables, but physical memory itself is already fairly 'reasonably dense' to
begin with. One single cache line of any upper level page table will cover
quite a bit of memory.
You're likely better off just trying to use large pages for the virtual
machine memory layout, which helps in other ways too. But when that fails,I
doubt it helps a lot to try to do fancy page table layout.
All gut feelings, but i seriously doubt any extra complexity would be a win
big enough to make up for the complexity costs..
Linus
[-- Attachment #2: Type: text/html, Size: 1721 bytes --]
next prev parent reply other threads:[~2017-06-14 22:58 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 4:56 Andy Lutomirski
2017-06-14 4:56 ` [PATCH v2 01/10] x86/ldt: Simplify LDT switching logic Andy Lutomirski
2017-06-15 18:53 ` Rik van Riel
2017-06-14 4:56 ` [PATCH v2 02/10] x86/mm: Remove reset_lazy_tlbstate() Andy Lutomirski
2017-06-15 19:29 ` Rik van Riel
2017-06-14 4:56 ` [PATCH v2 03/10] x86/mm: Give each mm TLB flush generation a unique ID Andy Lutomirski
2017-06-14 15:54 ` Dave Hansen
2017-06-14 17:16 ` Andy Lutomirski
2017-06-14 4:56 ` [PATCH v2 04/10] x86/mm: Track the TLB's tlb_gen and update the flushing algorithm Andy Lutomirski
2017-06-14 4:56 ` [PATCH v2 05/10] x86/mm: Rework lazy TLB mode and TLB freshness tracking Andy Lutomirski
2017-06-14 6:09 ` Juergen Gross
2017-06-19 22:00 ` Andy Lutomirski
2017-06-14 22:33 ` Dave Hansen
2017-06-14 22:42 ` Andy Lutomirski
2017-06-18 8:06 ` Nadav Amit
2017-06-19 21:58 ` Andy Lutomirski
2017-06-14 4:56 ` [PATCH v2 06/10] x86/mm: Stop calling leave_mm() in idle code Andy Lutomirski
2017-06-14 4:56 ` [PATCH v2 07/10] x86/mm: Disable PCID on 32-bit kernels Andy Lutomirski
2017-06-14 4:56 ` [PATCH v2 08/10] x86/mm: Add nopcid to turn off PCID Andy Lutomirski
2017-06-14 4:56 ` [PATCH v2 09/10] x86/mm: Enable CR4.PCIDE on supported systems Andy Lutomirski
2017-06-14 5:30 ` Juergen Gross
2017-06-14 4:56 ` [PATCH v2 10/10] x86/mm: Try to preserve old TLB entries using PCID Andy Lutomirski
2017-06-18 6:26 ` Nadav Amit
2017-06-19 22:02 ` Andy Lutomirski
2017-06-19 22:53 ` Nadav Amit
2017-06-19 23:04 ` Nadav Amit
2017-06-14 22:18 ` [PATCH v2 00/10] PCID and improved laziness Dave Hansen
2017-06-14 22:48 ` Andy Lutomirski
[not found] ` <CA+55aFw_PYteXjaFZw0vkn4XgOomaqN3JWN-NDh_HdaN8Jb0ZA@mail.gmail.com>
[not found] ` <CA+55aFxzXmg3Kkk+NaXYFy4JsQpbUcZ+CGTgTqAdOsOGqA_E_Q@mail.gmail.com>
2017-06-14 22:58 ` Linus Torvalds [this message]
2017-06-18 21:29 ` Levin, Alexander (Sasha Levin)
2017-06-19 4:43 ` Andy Lutomirski
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='CA+55aFyN_iA4CwVdEvwv4bWu1Y-ihsYcskcCD93=DGahown7sQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mgorman@suse.de \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox