From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1454829553-29499-1-git-send-email-ross.zwisler@linux.intel.com> <1454829553-29499-3-git-send-email-ross.zwisler@linux.intel.com> <20160207215047.GJ31407@dastard> <20160208201808.GK27429@dastard> Date: Mon, 8 Feb 2016 14:05:34 -0800 Message-ID: Subject: Re: [PATCH 2/2] dax: move writeback calls into the filesystems From: Dan Williams Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org To: Jeff Moyer Cc: Dave Chinner , Ross Zwisler , "linux-kernel@vger.kernel.org" , Theodore Ts'o , Alexander Viro , Andreas Dilger , Andrew Morton , Jan Kara , Matthew Wilcox , linux-ext4 , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , XFS Developers List-ID: On Mon, Feb 8, 2016 at 12:58 PM, Jeff Moyer wrote: > Dan Williams writes: > >> I agree the mount option needs to die, and I fully grok the reasoning. >> What I'm concerned with is that a system using fully-DAX-aware >> applications is forced to incur the overhead of maintaining *sync >> semantics, periodic sync(2) in particular, even if it is not relying >> on those semantics. >> >> However, like I said in my other mail, we can solve that with >> alternate interfaces to persistent memory if that becomes an issue and >> not require that "disable *sync" capability to come through DAX. > > What do you envision these alternate interfaces looking like? Well, plan-A was making DAX be explicit opt-in for applications, I haven't thought too much about plan-B. I expect it to be driven by real performance numbers and application use cases once the *sync compat work completes. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932276AbcBHWGM (ORCPT ); Mon, 8 Feb 2016 17:06:12 -0500 Received: from mail-yw0-f173.google.com ([209.85.161.173]:34774 "EHLO mail-yw0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756594AbcBHWFe (ORCPT ); Mon, 8 Feb 2016 17:05:34 -0500 MIME-Version: 1.0 In-Reply-To: References: <1454829553-29499-1-git-send-email-ross.zwisler@linux.intel.com> <1454829553-29499-3-git-send-email-ross.zwisler@linux.intel.com> <20160207215047.GJ31407@dastard> <20160208201808.GK27429@dastard> Date: Mon, 8 Feb 2016 14:05:34 -0800 Message-ID: Subject: Re: [PATCH 2/2] dax: move writeback calls into the filesystems From: Dan Williams To: Jeff Moyer Cc: Dave Chinner , Ross Zwisler , "linux-kernel@vger.kernel.org" , "Theodore Ts'o" , Alexander Viro , Andreas Dilger , Andrew Morton , Jan Kara , Matthew Wilcox , linux-ext4 , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , XFS Developers Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 8, 2016 at 12:58 PM, Jeff Moyer wrote: > Dan Williams writes: > >> I agree the mount option needs to die, and I fully grok the reasoning. >> What I'm concerned with is that a system using fully-DAX-aware >> applications is forced to incur the overhead of maintaining *sync >> semantics, periodic sync(2) in particular, even if it is not relying >> on those semantics. >> >> However, like I said in my other mail, we can solve that with >> alternate interfaces to persistent memory if that becomes an issue and >> not require that "disable *sync" capability to come through DAX. > > What do you envision these alternate interfaces looking like? Well, plan-A was making DAX be explicit opt-in for applications, I haven't thought too much about plan-B. I expect it to be driven by real performance numbers and application use cases once the *sync compat work completes. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 444C07CA2 for ; Mon, 8 Feb 2016 16:05:39 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 343A48F8040 for ; Mon, 8 Feb 2016 14:05:36 -0800 (PST) Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com [209.85.161.170]) by cuda.sgi.com with ESMTP id aX1d6S6gEX8Ov3zB (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 08 Feb 2016 14:05:34 -0800 (PST) Received: by mail-yw0-f170.google.com with SMTP id q190so113406520ywd.3 for ; Mon, 08 Feb 2016 14:05:34 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1454829553-29499-1-git-send-email-ross.zwisler@linux.intel.com> <1454829553-29499-3-git-send-email-ross.zwisler@linux.intel.com> <20160207215047.GJ31407@dastard> <20160208201808.GK27429@dastard> Date: Mon, 8 Feb 2016 14:05:34 -0800 Message-ID: Subject: Re: [PATCH 2/2] dax: move writeback calls into the filesystems From: Dan Williams List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Jeff Moyer Cc: Theodore Ts'o , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , XFS Developers , Linux MM , Andreas Dilger , Alexander Viro , Jan Kara , linux-fsdevel , Matthew Wilcox , Ross Zwisler , linux-ext4 , Andrew Morton On Mon, Feb 8, 2016 at 12:58 PM, Jeff Moyer wrote: > Dan Williams writes: > >> I agree the mount option needs to die, and I fully grok the reasoning. >> What I'm concerned with is that a system using fully-DAX-aware >> applications is forced to incur the overhead of maintaining *sync >> semantics, periodic sync(2) in particular, even if it is not relying >> on those semantics. >> >> However, like I said in my other mail, we can solve that with >> alternate interfaces to persistent memory if that becomes an issue and >> not require that "disable *sync" capability to come through DAX. > > What do you envision these alternate interfaces looking like? Well, plan-A was making DAX be explicit opt-in for applications, I haven't thought too much about plan-B. I expect it to be driven by real performance numbers and application use cases once the *sync compat work completes. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs