From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933905AbeEWRqc (ORCPT ); Wed, 23 May 2018 13:46:32 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:33644 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932667AbeEWRq3 (ORCPT ); Wed, 23 May 2018 13:46:29 -0400 X-Google-Smtp-Source: AB8JxZpFFjL8OCn3mBII83AAy8AqD7gavx0Xv8ia1huv085n3WqG3o54LA1jXD9ZwWuVzuGQ8i6mZg== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU From: Nadav Amit In-Reply-To: <5e20be19-28ba-189a-6935-698a012a6665@linux.intel.com> Date: Wed, 23 May 2018 10:46:26 -0700 Cc: Matthew Wilcox , Christopher Lameter , Boaz Harrosh , Jeff Moyer , Andrew Morton , "Kirill A. Shutemov" , linux-kernel , linux-fsdevel , "linux-mm@kvack.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Peter Zijlstra , Rik van Riel , Jan Kara , Matthew Wilcox , Amit Golander Message-Id: <45CBAC53-610A-485B-95D8-4357261338BF@gmail.com> References: <0efb5547-9250-6b6c-fe8e-cf4f44aaa5eb@netapp.com> <20180514191551.GA27939@bombadil.infradead.org> <7ec6fa37-8529-183d-d467-df3642bcbfd2@netapp.com> <20180515004137.GA5168@bombadil.infradead.org> <010001637399f796-3ffe3ed2-2fb1-4d43-84f0-6a65b6320d66-000000@email.amazonses.com> <5aea6aa0-88cc-be7a-7012-7845499ced2c@netapp.com> <50cbc27f-0014-0185-048d-25640f744b5b@linux.intel.com> <0100016388be5738-df8f9d12-7011-4e4e-ba5b-33973e5da794-000000@email.amazonses.com> <20180522175114.GA1237@bombadil.infradead.org> <5e20be19-28ba-189a-6935-698a012a6665@linux.intel.com> To: Dave Hansen X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id w4NHkb1r013415 Dave Hansen wrote: > On 05/22/2018 10:51 AM, Matthew Wilcox wrote: >> But CR3 is a per-CPU register. So it'd be *possible* to allocate one >> PGD per CPU (per process). Have them be identical in all but one of >> the PUD entries. Then you've reserved 1/512 of your address space for >> per-CPU pages. >> >> Complicated, ugly, memory-consuming. But possible. > > Yep, and you'd probably want a cache of them so you don't end up having > to go rewrite half of the PGD every time you context-switch. But, on > the plus side, the logic would be pretty similar if not identical to the > way that we manage PCIDs. If your mm was recently active on the CPU, > you can use a PGD that's already been constructed. If not, you're stuck > making a new one. > > Andy L. was alto talking about using this kind of mechanism to simplify > the entry code. Instead of needing per-cpu areas where we index by the > CPU number, or by using %GS, we could have per-cpu data or code that has > a fixed virtual address. > > It'd be a fun project, but it might not ever pan out. For the record: there are several academic studies about this subject. The most notable one is Corey [1]. [1] https://www.usenix.org/legacy/event/osdi08/tech/full_papers/boyd-wickizer/boyd_wickizer.pdf