From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by kanga.kvack.org (Postfix) with ESMTP id 6D1ED6B0009 for ; Tue, 23 Feb 2016 18:56:18 -0500 (EST) Received: by mail-ob0-f174.google.com with SMTP id dm2so2080840obb.2 for ; Tue, 23 Feb 2016 15:56:18 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com. [2607:f8b0:4003:c06::22b]) by mx.google.com with ESMTPS id dq4si154994oeb.52.2016.02.23.15.56.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2016 15:56:17 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id x21so1604005oix.2 for ; Tue, 23 Feb 2016 15:56:17 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <56C9EDCF.8010007@plexistor.com> <56CA1CE7.6050309@plexistor.com> <56CA2AC9.7030905@plexistor.com> <20160221223157.GC25832@dastard> <20160222174426.GA30110@infradead.org> <257B23E37BCB93459F4D566B5EBAEAC550098A32@FMSMSX106.amr.corp.intel.com> <20160223095225.GB32294@infradead.org> <56CC686A.9040909@plexistor.com> <56CCD54C.3010600@plexistor.com> Date: Tue, 23 Feb 2016 15:56:17 -0800 Message-ID: Subject: Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag From: Dan Williams Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Jeff Moyer Cc: Boaz Harrosh , Christoph Hellwig , "Rudoff, Andy" , Dave Chinner , Arnd Bergmann , linux-nvdimm , Oleg Nesterov , linux-mm , Mel Gorman , Johannes Weiner , "Kirill A. Shutemov" On Tue, Feb 23, 2016 at 3:43 PM, Jeff Moyer wrote: > Dan Williams writes: > >> On Tue, Feb 23, 2016 at 3:28 PM, Jeff Moyer wrote: >>>> The crux of the problem, in my opinion, is that we're asking for an "I >>>> know what I'm doing" flag, and I expect that's an impossible statement >>>> for a filesystem to trust generically. >>> >>> The file system already trusts that. If an application doesn't use >>> fsync properly, guess what, it will break. This line of reasoning >>> doesn't make any sense to me. >> >> No, I'm worried about the case where an app specifies MAP_PMEM_AWARE >> uses fsync correctly, and fails to flush cpu cache. > > I don't think the kernel needs to put training wheels on applications. > >>>> If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the >>>> opinion that the "I know what I'm doing" interface should be something >>>> separate from today's trusted filesystems. >>> >>> Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm >>> doing" interface, right? >> >> It is the "I know what I'm doing" interface, MAP_PMEM_AWARE asserts "I >> know when to flush the cpu relative to an fsync()". > > I see. So I think your argument is that new file systems (such as Nova) > can have whacky new semantics, but existing file systems should provide > the more conservative semantics that they have provided since the dawn > of time (even if we add a new mmap flag to control the behavior). > > I don't agree with that. :) > Fair enough. Recall, I was pushing MAP_DAX not to long ago. It just seems like a Sisyphean effort to push an mmap flag up the XFS hill and maybe that effort is better spent somewhere else. -- 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