Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp2004151ybg; Thu, 24 Oct 2019 03:28:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqx3s2LvxXX7N/whmxac2hMIEs/2IWBfeh4orC8/w57V0PeCq7YPsAag5ltUBFMx++vLxnCV X-Received: by 2002:aa7:cd01:: with SMTP id b1mr13804716edw.122.1571912920763; Thu, 24 Oct 2019 03:28:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571912920; cv=none; d=google.com; s=arc-20160816; b=E18Y3/cNDkY6I+uTu68kaa37F+np2OgfNw8cCzOnBkxj1KWSsTQA8DKFVEdgh704Eh g7DHAjj3C5BN67596xcnDWmRMANMXu0XwoNysW6JX/ma/7wCrkpwZoF37WSywHTWc/nY 7ltJJi/wVyOeHhR+iK8/Dh/mWah4A1cAryQlFqFrLLjwSy6187H7zElFHvtckpsvR7hT 4tWmZoWQOP6pyGdLO7uy4vGwgiNG61vFwaIjj7f+PO9+qIbY+nrsvHO6YbQb2m6Svzwt SfHFtAN2s/9g2IBYJI4GFsKG8O4iqmjzWGBkgzrjxn7WO1FuhwuuztvtRer64+l0mgV/ XReA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=cyFunkhvHm3NOzxc3iNdeX6ePGfP/aq9rFnS6d8iDGI=; b=EtqXPzoeFZuBJtma97SZBA6/dK0Cbv+de/4AxFgBnxbbuJmotklT4fh6Hb0vns67Sp 22m2IdTT0F9vgSg7k4kme25wC5080J6Z3Xb0h7iqZ4w6NUD5l6PmyMQrFT1/BLtleKPM 5OtQn6df60spRIBrUExBSUGlE20cawxcox3KrB1gFhIN/blJtLgAurfkhs2BpDLPU+4l yFo2Wlff41l+g26+Hcy67YmtXla0d02+NgtikatTeYxczpLyqXOtvGKR/TfwgYNMOqLK VE2KcaaoAaq991RH4/Uvvn1x/hFhoWYZEGstsp7UH60ydJPdhtLc8hJLEHsAVPLOuD19 lmqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-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 z3si14530100ejb.42.2019.10.24.03.28.08; Thu, 24 Oct 2019 03:28:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2436700AbfJWWNo (ORCPT + 99 others); Wed, 23 Oct 2019 18:13:44 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:39940 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2436687AbfJWWNo (ORCPT ); Wed, 23 Oct 2019 18:13:44 -0400 Received: from dread.disaster.area (pa49-180-40-48.pa.nsw.optusnet.com.au [49.180.40.48]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 00C6E43EE24; Thu, 24 Oct 2019 09:13:34 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1iNOsm-0006fc-Rc; Thu, 24 Oct 2019 09:13:32 +1100 Date: Thu, 24 Oct 2019 09:13:32 +1100 From: Dave Chinner To: Boaz Harrosh Cc: ira.weiny@intel.com, linux-kernel@vger.kernel.org, Alexander Viro , "Darrick J. Wong" , Dan Williams , Christoph Hellwig , "Theodore Y. Ts'o" , Jan Kara , linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 0/5] Enable per-file/directory DAX operations Message-ID: <20191023221332.GE2044@dread.disaster.area> References: <20191020155935.12297-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=D+Q3ErZj c=1 sm=1 tr=0 a=y881pOMu+B+mZdf5UrsJdA==:117 a=y881pOMu+B+mZdf5UrsJdA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=XobE76Q3jBoA:10 a=QyXUC8HyAAAA:8 a=7-415B0cAAAA:8 a=iEe7G1TxEPlCt2B0xWcA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Oct 23, 2019 at 04:09:50PM +0300, Boaz Harrosh wrote: > On 22/10/2019 14:21, Boaz Harrosh wrote: > > On 20/10/2019 18:59, ira.weiny@intel.com wrote: > Please explain the use case behind your model? No application changes needed to control whether they use DAX or not. It allows the admin to control the application behaviour completely, so they can turn off DAX if necessary. Applications are unaware of constraints that may prevent DAX from being used, and so admins need a mechanism to prevent DAX aware application from actually using DAX if the capability is present. e.g. given how slow some PMEM devices are when it comes to writing data, especially under extremely high concurrency, DAX is not necessarily a performance win for every application. Admins need a guaranteed method of turning off DAX in these situations - apps may not provide such a knob, or even be aware of a thing called DAX... e.g. the data set being accessed by the application is mapped and modified by RDMA applications, so those files must not be accessed using DAX by any application because DAX+RDMA are currently incompatible. Hence you can have RDMA on pmem devices co-exist within the same filesystem as other applications using DAX to access the pmem... Cheers, Dave. -- Dave Chinner david@fromorbit.com