Received: by 2002:ac0:8c8e:0:0:0:0:0 with SMTP id r14csp1199530ima; Wed, 6 Feb 2019 15:43:54 -0800 (PST) X-Google-Smtp-Source: AHgI3IZBpbXTNLVgd1WIRpQy4RtzQzClApIQf9NbtV8aCaueiDjihq6OcqxvEu6H7KoZDRzsqE/s X-Received: by 2002:a62:5486:: with SMTP id i128mr12885716pfb.215.1549496633961; Wed, 06 Feb 2019 15:43:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549496633; cv=none; d=google.com; s=arc-20160816; b=XBr+fN1Vc1kITwFmCsRQWU6ySLSdTrD4wUa8Til+ES1BXVK3tZchnklzBLUc0r3eSw L2UIiJK2NjuEnACJ4KLX6ODw4objMdJ2zsaHG4OpSN2N/Ruy9ySiZHklv5pF1oh3A3BJ +sPI/HbVOqP7UtGdCOzQFZUyYJYG6WPBo6w+5rBQcv7CxCZP4+B3AMXiQUG3713cEPkJ jg7d7MumMdVoJKT6oOV2J2rSkCraPZKkL3Yen+uqbt9RouQdavGZOSfBgljK81niZp8p PIJ9IugnBxMMJhSLl5bc508eRrwproLgVAmi28tB4OIrA3KajIqL6LCNrxz0JQAnGrUR hU5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=mXx8poVQjV9HwQ463+J8Xh3rIF5Pas5UKY3iVculMOM=; b=g7SN3PsU6kLCfVYuPDJVTorhI/PlnHu6XFDaV2xmIjdByTHCkAhSJXchM6uORvuQ5V Ise9kZb4KzXYIgaQDFJXc+6HcWnuBsM5jhMDsSYvwwz7bmve/bNxxRpqr+yLgyAZvoG/ 2j2y2ZHb7Ee5cqCM9YrRMciO9hH03ejoptXDuLil5H5pbvIokSx5KD9glqxgRJRFlXc/ kKojgkCOFHt+zQfkJihlQwebwVWFqc5nMDKybVqY7rQCj/ziFZSiWY9oPD9DSmpuOGMf 0HdHTesCZdeVvFWewCOxKsxGR27PFtLHhEgxbUNci1UJ2Ls/u5pF9Yxg9NySL3erCtDM lyow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=Z3Z2lLvk; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j5si6666759pgq.82.2019.02.06.15.43.38; Wed, 06 Feb 2019 15:43:53 -0800 (PST) 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=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=Z3Z2lLvk; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726567AbfBFXmd (ORCPT + 99 others); Wed, 6 Feb 2019 18:42:33 -0500 Received: from mail-ot1-f48.google.com ([209.85.210.48]:45082 "EHLO mail-ot1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726161AbfBFXmc (ORCPT ); Wed, 6 Feb 2019 18:42:32 -0500 Received: by mail-ot1-f48.google.com with SMTP id 32so15144676ota.12 for ; Wed, 06 Feb 2019 15:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mXx8poVQjV9HwQ463+J8Xh3rIF5Pas5UKY3iVculMOM=; b=Z3Z2lLvknU+nXiktZsISNTZLCCnSxgLh9jbswTAZpFimWum7i8r4fiyXlbRXawiSFx ubZthob+CbYbDMN5OCG6J2F9X3wECf+LBU+tTop4TVjaWjls++ZNfLtg+1JGYnPEcN37 EaNJwmPl89UKy8gR+WlqBXdJkRZg16QJ0BjDH4q+Sx6RPbFi1tr2TZb/EHnIeM4dOWHF wHzB/rU13hd17CbU1+HNk9CJoObq4xDh7x4aC/CDMcamLw4e/S1MrwMzMk7bxycUqbgS InxU0buRpVtfqCYuDLJanWPCzbVAjVkTWMWCnP0VW6BH5bVPjHYS4iqebcD180jVB1rC q3Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mXx8poVQjV9HwQ463+J8Xh3rIF5Pas5UKY3iVculMOM=; b=JRxSIZfS4MlooJ05F9U4V8n/qI5dHrFwt2NZq9EWctpUaVgCy2ZF4jKhTFgp+d7bIa ay0+qmoOm/56wFETL4QTaxXf75fTKTjox3kLwHROGddt3uaH+FGIpJURPKDMREUHWDJo /SAiQZzA7Q89/lLNHIe02Oo7xQu0B0ufdPU/UL9yFNLA4kw364h3UXLq4RuP1ZlRc9mp Vk1u30UYDKY4X6/+POHcVr4FiH3o790vpVER8eSaUXzOuMFSYc+faYZM66RefeRdBgHF bDpRwdiSov5aCgnc9BJ+sNPyTI3g5nInySKfe9tgHv8jKs3TSyBWXPYcyZpM/CB1ZtEm yylA== X-Gm-Message-State: AHQUAuZwIy15d9XIrhtAfNS27mOrBpt0SpCON2YkHwC+M7cFmoTUdSjJ vbeLwc/QXBQfYOE1mzJJyBsc5GBQxigaKh1QxwnfYQ== X-Received: by 2002:aca:240a:: with SMTP id n10mr956698oic.73.1549496551785; Wed, 06 Feb 2019 15:42:31 -0800 (PST) MIME-Version: 1.0 References: <20190206231706.GB23860@ubuette> In-Reply-To: <20190206231706.GB23860@ubuette> From: Dan Williams Date: Wed, 6 Feb 2019 15:42:17 -0800 Message-ID: Subject: Re: question about mmap MAP_PRIVATE on PMEM/DAX/fs files To: Larry Bassel Cc: linux-nvdimm , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 6, 2019 at 3:17 PM Larry Bassel wrote: > > Is mmaping a PMEM/DAX/fs file MAP_PRIVATE supported? Yes. > Is it something > that people are likely to want to do? MAP_PRIVATE for file backed mappings is useful for processes to read common data as input, but hide their writes to that data. > If it is supported, suppose I open a file in PMEM/DAX/fs, mmap it > MAP_PRIVATE, read from the memory mapped file (with memory accesses, > not the read syscall) and take a page fault which the kernel satisfies. > > At this time do my page tables for the private mmaped page(s) point to the > PMEM corresponding to the file and the kernel will wait until > the page(s) is/are altered (either by me or someone else) to > copy on write and give me a different page/mapping? For this example let's assume the filesystem already allocated capacity for the file at the given offset, otherwise the kernel is free to map in a zero page to cover holes in the file. > Or does the kernel avoid this by always mapping a copy of the > page(s) involved in the private mmap in the first place? > At read-fault time the page tables point to the direct PMEM page for the file allocation, for a write fault a "System RAM" page is mapped in place of PMEM. > In either case, is my private copy going to come from PMEM or is it > an "ordinary" page, or is this "random"? Does the program have > any choice in this (i.e. suppose I want to make sure my copied > page is persistent)? No, the copied page will never be persisted. From the mmap() man page: "Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file."