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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 AE24DC4727C for ; Tue, 22 Sep 2020 15:44:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 799CC2399A for ; Tue, 22 Sep 2020 15:44:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726667AbgIVPoB (ORCPT ); Tue, 22 Sep 2020 11:44:01 -0400 Received: from mga05.intel.com ([192.55.52.43]:47272 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726566AbgIVPoA (ORCPT ); Tue, 22 Sep 2020 11:44:00 -0400 IronPort-SDR: 5bc38UqX+uuwKTYbu+imdSTQ0tG36TLQnS7WFjdMHacoHyqa3qhO2p0DYxRpxOMfcDhz6Bsf/O bNAW32O2VTMA== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="245468157" X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="245468157" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.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 Cc: Dan Williams , Linus Torvalds , Alexander Viro , Andrew Morton , Vishal Verma , Dave Jiang , Matthew Wilcox , Jan Kara , Eric Sandeen , Dave Chinner , "Kani, Toshi" , "Norton, Scott J" , "Tadakamadla, Rajesh (DCIG/CDI/HPS Perf)" , Linux Kernel Mailing List , linux-fsdevel , linux-nvdimm Subject: Re: [RFC] nvfs: a filesystem for persistent memory Message-ID: <20200922154359.GT2540965@iweiny-DESK2.sc.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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 >