From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <20181002100531.GC4135@quack2.suse.cz> <20181002121039.GA3274@linux-x5ow.site> <20181002142010.GB4963@linux-x5ow.site> <20181002144547.GA26735@infradead.org> <20181002150123.GD4963@linux-x5ow.site> <20181002150634.GA22209@infradead.org> <20181004100949.GF6682@linux-x5ow.site> <20181005062524.GA30582@infradead.org> <20181005063519.GA5491@linux-x5ow.site> In-Reply-To: <20181005063519.GA5491@linux-x5ow.site> From: Dan Williams Date: Fri, 5 Oct 2018 18:17:29 -0700 Message-ID: Subject: Re: Problems with VM_MIXEDMAP removal from /proc//smaps To: Johannes Thumshirn Cc: Christoph Hellwig , Jan Kara , linux-fsdevel , Linux MM , linux-nvdimm , Michal Hocko Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: On Thu, Oct 4, 2018 at 11:35 PM Johannes Thumshirn wrote: > > On Thu, Oct 04, 2018 at 11:25:24PM -0700, Christoph Hellwig wrote: > > Since when is an article on some website a promise (of what exactly) > > by linux kernel developers? > > Let's stop it here, this doesn't make any sort of forward progress. > I do think there is some progress we can make if we separate DAX as an access mechanism vs DAX as a resource utilization contract. My attempt at representing Christoph's position is that the kernel should not be advertising / making access mechanism guarantees. That makes sense. Even with MAP_SYNC+DAX the kernel reserves the right to write-protect mappings at will and trap access into a kernel handler. Additionally, whether read(2) / write(2) does anything different behind the scenes in DAX mode, or not should be irrelevant to the application. That said what is certainly not irrelevant is a kernel giving userspace visibility and control into resource utilization. Jan's MADV_DIRECT_ACCESS let's the application make assumptions about page cache utilization, we just need to another mechanism to read if a mapping is effectively already in that state.