From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by kanga.kvack.org (Postfix) with ESMTP id 332AA6B0005 for ; Thu, 25 Feb 2016 15:20:55 -0500 (EST) Received: by mail-ig0-f182.google.com with SMTP id z8so21750448ige.0 for ; Thu, 25 Feb 2016 12:20:55 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net. [150.101.137.129]) by mx.google.com with ESMTP id m65si12326482ioa.163.2016.02.25.12.20.53 for ; Thu, 25 Feb 2016 12:20:54 -0800 (PST) Date: Fri, 26 Feb 2016 07:15:17 +1100 From: Dave Chinner Subject: Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag Message-ID: <20160225201517.GA30721@dastard> References: <56CCD54C.3010600@plexistor.com> <20160224225623.GL14668@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Jeff Moyer Cc: Arnd Bergmann , linux-nvdimm , Oleg Nesterov , Christoph Hellwig , linux-mm , Mel Gorman , Johannes Weiner , "Kirill A. Shutemov" On Thu, Feb 25, 2016 at 02:11:49PM -0500, Jeff Moyer wrote: > Jeff Moyer writes: > > >> The big issue we have right now is that we haven't made the DAX/pmem > >> infrastructure work correctly and reliably for general use. Hence > >> adding new APIs to workaround cases where we haven't yet provided > >> correct behaviour, let alone optimised for performance is, quite > >> frankly, a clear case premature optimisation. > > > > Again, I see the two things as separate issues. You need both. > > Implementing MAP_SYNC doesn't mean we don't have to solve the bigger > > issue of making existing applications work safely. > > I want to add one more thing to this discussion, just for the sake of > clarity. When I talk about existing applications and pmem, I mean > applications that already know how to detect and recover from torn > sectors. Any application that assumes hardware does not tear sectors > should be run on a file system layered on top of the btt. Which turns off DAX, and hence makes this a moot discussion because mmap is then buffered through the page cache and hence applications *must use msync/fsync* to provide data integrity. Which also makes them safe to use with DAX if we have a working fsync. Keep in mind that existing storage technologies tear fileystem data writes, too, because user data writes are filesystem block sized and not atomic at the device level (i.e. typical is 512 byte sector, 4k filesystem block size, so there are 7 points in a single write where a tear can occur on a crash). IOWs existing storage already has the capability of tearing user data on crash and has been doing so for a least they last 30 years. Hence I really don't see any fundamental difference here with pmem+DAX - the only difference is that the tear granuarlity is smaller (CPU cacheline rather than sector). Cheers, Dave. -- Dave Chinner david@fromorbit.com -- 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