From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B82EC2D0E2 for ; Tue, 22 Sep 2020 15:44:04 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 733242388B for ; Tue, 22 Sep 2020 15:44:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 733242388B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id A9371142AE4FB; Tue, 22 Sep 2020 08:44:02 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=192.55.52.151; helo=mga17.intel.com; envelope-from=ira.weiny@intel.com; receiver= Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2C438142638AD for ; Tue, 22 Sep 2020 08:44:01 -0700 (PDT) IronPort-SDR: KLiVLeOzp6wtx/9iMSJXbxZLvNY4YP5/yAYMk5z8W0x2nNMg1CDyIVdQ3Ewb2gTgPCHAQgAbBD U/CveLhS8Ilw== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="140639226" X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="140639226" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 08:44:00 -0700 IronPort-SDR: CrBX6uCXF/Ea+FOpNE7cJh8tZR89yO3TH83yCb8vusQ0t2a2qis7v6kd/QGYtfr1T+ca/2ACIf 8+8dfadffPrg== X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="486006776" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 08:44:00 -0700 Date: Tue, 22 Sep 2020 08:43:59 -0700 From: Ira Weiny To: Mikulas Patocka Subject: Re: [RFC] nvfs: a filesystem for persistent memory Message-ID: <20200922154359.GT2540965@iweiny-DESK2.sc.intel.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Message-ID-Hash: 6IZOOGU7AJTUHCTN4ZTAOVIUFHTW3VMO X-Message-ID-Hash: 6IZOOGU7AJTUHCTN4ZTAOVIUFHTW3VMO X-MailFrom: ira.weiny@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Linus Torvalds , Alexander Viro , Andrew Morton , Matthew Wilcox , Jan Kara , Eric Sandeen , Dave Chinner , "Tadakamadla, Rajesh (DCIG/CDI/HPS Perf)" , Linux Kernel Mailing List , linux-fsdevel , linux-nvdimm X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Sep 21, 2020 at 12:19:07PM -0400, Mikulas Patocka wrote: > > > On Tue, 15 Sep 2020, Dan Williams wrote: > > > > TODO: > > > > > > - programs run approximately 4% slower when running from Optane-based > > > persistent memory. Therefore, programs and libraries should use page cache > > > and not DAX mapping. > > > > This needs to be based on platform firmware data f(ACPI HMAT) for the > > relative performance of a PMEM range vs DRAM. For example, this > > tradeoff should not exist with battery backed DRAM, or virtio-pmem. > > Hi > > I have implemented this functionality - if we mmap a file with > (vma->vm_flags & VM_DENYWRITE), then it is assumed that this is executable > file mapping - the flag S_DAX on the inode is cleared on and the inode > will use normal page cache. > > Is there some way how to test if we are using Optane-based module (where > this optimization should be applied) or battery backed DRAM (where it > should not)? > > I've added mount options dax=never, dax=auto, dax=always, so that the user ^^^^^^^^ dax=inode? 'inode' is the option used by ext4/xfs. Ira > can override the automatic behavior. > > Mikulas > _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org