From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f70.google.com (mail-pa0-f70.google.com [209.85.220.70]) by kanga.kvack.org (Postfix) with ESMTP id 45BA06B0069 for ; Tue, 13 Sep 2016 01:41:06 -0400 (EDT) Received: by mail-pa0-f70.google.com with SMTP id fu12so116384293pac.1 for ; Mon, 12 Sep 2016 22:41:06 -0700 (PDT) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com. [2607:f8b0:400e:c03::243]) by mx.google.com with ESMTPS id xl3si25659841pab.117.2016.09.12.22.41.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Sep 2016 22:41:00 -0700 (PDT) Received: by mail-pa0-x243.google.com with SMTP id p2so2519999pap.3 for ; Mon, 12 Sep 2016 22:41:00 -0700 (PDT) Date: Tue, 13 Sep 2016 15:40:48 +1000 From: Nicholas Piggin Subject: Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps) Message-ID: <20160913154048.76b0e0bc@roar.ozlabs.ibm.com> In-Reply-To: References: <20160908225636.GB15167@linux.intel.com> <20160912052703.GA1897@infradead.org> <20160912075128.GB21474@infradead.org> <20160912180507.533b3549@roar.ozlabs.ibm.com> <20160912150148.GA10039@infradead.org> <20160913113128.4eae792e@roar.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Dan Williams Cc: Christoph Hellwig , Yumei Huang , Michal Hocko , Xiao Guangrong , KVM list , Dave Hansen , Gleb Natapov , "linux-nvdimm@lists.01.org" , mtosatti@redhat.com, "linux-kernel@vger.kernel.org" , Linux MM , Stefan Hajnoczi , linux-fsdevel , Paolo Bonzini , Andrew Morton On Mon, 12 Sep 2016 21:06:49 -0700 Dan Williams wrote: > On Mon, Sep 12, 2016 at 6:31 PM, Nicholas Piggin wrote: > > On Mon, 12 Sep 2016 08:01:48 -0700 > [..] > > That said, a noop system call is on the order of 100 cycles nowadays, > > so rushing to implement these APIs without seeing good numbers and > > actual users ready to go seems premature. *This* is the real reason > > not to implement new APIs yet. > > Yes, and harvesting the current crop of low hanging performance fruit > in the filesystem-DAX I/O path remains on the todo list. > > In the meantime we're pursuing this mm api, mincore+ or whatever we > end up with, to allow userspace to distinguish memory address ranges > that are backed by a filesystem requiring coordination of metadata > updates + flushes for updates, vs something like device-dax that does > not. Yes, that's reasonable. Do you need page/block granularity? Do you need a way to advise/request the fs for a particular capability? Is it enough to request and check success? Would the capability be likely to change, and if so, how would you notify the app asynchronously? -- 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