Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1869909imm; Tue, 22 May 2018 10:37:35 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq2JhGympBSiTVAbSgxyKg0NSH9OIZvSSPIgXwlB6sWB2TIifru2NcVx7UIX2eA1glU5sYo X-Received: by 2002:a62:c485:: with SMTP id h5-v6mr25630110pfk.86.1527010655143; Tue, 22 May 2018 10:37:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527010655; cv=none; d=google.com; s=arc-20160816; b=m4Aemocmr7lcB7HweOrnehSvUePYkZGb1hydnSXNn/Y1FvGV185r8JiS23JNLbHiRn cWUqp49JxwANMVhjhcgXkICeGnPN4/JnAYEAUDrjPfyYVOvGg8FwUvWgFXa23kI/BnkH gp/iCSgOqbECczTDzZxDa97c130blD3Y+umdTu/N9+bbeda86VNbSXs3aNRbyGttTH61 Q6CQPSwQ9v7RsgxqPdoSJ2RFWtTQFbNNs/5gcaltYDltI4nYshdwNEbCEsR0Ich6V6WM zVzN04gOY0d4sKJmsajxurPN1eh/zE0IL5tpeyB0B8ZNIX3DCH+zduolHxCjfRh3v9/l +0iA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:feedback-id:mime-version:user-agent :references:message-id:in-reply-to:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=ISalpPIQdO9aFkqBoZHKUdYX8WP/AJ0Jzc5Iqq4Ar9o=; b=x08QTgEjVP5O5LUybFueCsIvjVFD+9iWwV4FXWCevhAs917/DulT2jdqpNZ6Pu78hh ONmlWyGnBFFpe7u4DPUdBMuR7Oc/3a4lr3Qdet7yKU+XvbUi1VPyv5SKEjFd2wLV1I6F L3djJMD5TKyugZWRjQrw4UUXDs+plHyRUgZdsHNWzIjrYQiREbIdKJZLoS0WvNtyTvtO GH1GjrOxCq5JBV3R1DLmUF6O8uIN/4NhR8/6YCpew4U2DDEa8GnCSqurfZCV2hl0x/0g sQ5JpKmZNY4ecsfT2M5RINgrp13inGZYvCaG3P6Vs9m+bCldiHUXf2MT7UTfbYOXA2WU 3Fmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=ZQj5sgpK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y1-v6si13514042pge.248.2018.05.22.10.37.14; Tue, 22 May 2018 10:37:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=ZQj5sgpK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752096AbeEVRfG (ORCPT + 99 others); Tue, 22 May 2018 13:35:06 -0400 Received: from a9-112.smtp-out.amazonses.com ([54.240.9.112]:50294 "EHLO a9-112.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349AbeEVRfF (ORCPT ); Tue, 22 May 2018 13:35:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1527010504; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Feedback-ID; bh=yQcVbMcpNbLGrhAqTiNnqpfQz7CUnzCCW9xdyiOvVSY=; b=ZQj5sgpKRiRvHWhcp7V638KQcLcJKszw++zeRCUYrsu8IXZ5PwMQ8LaYkS7Ukye6 JARgNKqCM1NpRndCSKPRsmjJBpduxGWsZ6kYUesraoxcWP2honJ5PUzo84YI1Xh0DIj UcDBpBToFUDhmsfdMueRLWz/1DrJ9QIK6YyA5mzg= Date: Tue, 22 May 2018 17:35:04 +0000 From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Dave Hansen cc: Boaz Harrosh , Jeff Moyer , Matthew Wilcox , 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 Subject: Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU In-Reply-To: Message-ID: <0100016388eb2dd6-f4cf8960-26d0-4435-818e-d5105fe43eb3-000000@email.amazonses.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> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SES-Outgoing: 2018.05.22-54.240.9.112 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 22 May 2018, Dave Hansen wrote: > On 05/22/2018 09:46 AM, Christopher Lameter wrote: > > On Tue, 22 May 2018, Dave Hansen wrote: > > > >> On 05/22/2018 09:05 AM, Boaz Harrosh wrote: > >>> How can we implement "Private memory"? > >> Per-cpu page tables would do it. > > We already have that for percpu subsystem. See alloc_percpu() > > I actually mean a set of page tables which is only ever installed on a > single CPU. The CPU is architecturally allowed to go load any PTE in > the page tables into the TLB any time it feels like. The only way to > keep a PTE from getting into the TLB is not ensure that a CPU never has > any access to it, and the only way to do that is to make sure that no > set of page tables it ever loads into CR3 have that PTE. > > As Peter said, it's possible, but not pretty. Well yeah its much more pretty if you use the segment register to avoid the page table tricks on x86. Other arches may rely on page table tricks. Regardless of that the percpu subsystem was created to provide "private" memory for each cpu and that may be the right starting point for adding "local" memory.