From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f72.google.com (mail-it0-f72.google.com [209.85.214.72]) by kanga.kvack.org (Postfix) with ESMTP id E44FF6B0279 for ; Wed, 14 Jun 2017 18:58:19 -0400 (EDT) Received: by mail-it0-f72.google.com with SMTP id k26so1808394iti.5 for ; Wed, 14 Jun 2017 15:58:19 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com. [2607:f8b0:4001:c06::235]) by mx.google.com with ESMTPS id n14si1411957iti.100.2017.06.14.15.58.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 15:58:19 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id y77so1364331ioe.3 for ; Wed, 14 Jun 2017 15:58:19 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <6da4aea9-ef52-694d-9a03-285c32018326@intel.com> From: Linus Torvalds Date: Thu, 15 Jun 2017 07:58:18 +0900 Message-ID: Subject: Re: [PATCH v2 00/10] PCID and improved laziness Content-Type: multipart/alternative; boundary="001a11405e5af719e50551f37c55" Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Lutomirski Cc: Nadav Amit , Arjan van de Ven , Borislav Petkov , "linux-mm@kvack.org" , X86 ML , Andrew Morton , Dave Hansen , "linux-kernel@vger.kernel.org" , Mel Gorman , Peter Zijlstra , Rik van Riel --001a11405e5af719e50551f37c55 Content-Type: text/plain; charset="UTF-8" On Jun 15, 2017 7:48 AM, "Andy Lutomirski" 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 --001a11405e5af719e50551f37c55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Jun 15, 2017 7:48 AM, "Andy Lutomirski" <luto@kernel.org> wrote:

Then throw EPT into the mix for extra fun.=C2=A0 I wonder if we shoul= d 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 ma= pping.

Yes, for virtualization, the "virtual mappi= ng" ends up being those page tables, but physical memory itself is alr= eady 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 t= he virtual machine memory layout, which helps in other ways too. But when t= hat fails,I doubt it helps a lot to try to do fancy page table layout.

All gut feelings, but i seriously doubt any extra complexit= y would be a win big enough to make up for the complexity costs..

=C2=A0 =C2=A0 =C2=A0Linus
--001a11405e5af719e50551f37c55-- -- 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: email@kvack.org