From: Christoph Hellwig <hch@infradead.org> To: Johannes Thumshirn <jthumshirn@suse.de> Cc: mhocko@suse.cz, Jan Kara <jack@suse.cz>, linux-nvdimm@lists.01.org, Christoph Hellwig <hch@infradead.org>, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: Problems with VM_MIXEDMAP removal from /proc/<pid>/smaps Date: Tue, 2 Oct 2018 08:06:34 -0700 [thread overview] Message-ID: <20181002150634.GA22209@infradead.org> (raw) In-Reply-To: <20181002150123.GD4963@linux-x5ow.site> On Tue, Oct 02, 2018 at 05:01:24PM +0200, Johannes Thumshirn wrote: > On Tue, Oct 02, 2018 at 07:45:47AM -0700, Christoph Hellwig wrote: > > How does an application "make use of DAX"? What actual user visible > > semantics are associated with a file that has this flag set? > > There may not be any user visible semantics of DAX, but there are > promises we gave to application developers praising DAX as _the_ > method to map data on persistent memory and get around "the penalty of > the page cache" (however big this is). Who is "we"? As someone involved with DAX code I think it is a steaming pile of *****, and we are still looking for cases where it actually works without bugs. That's why the experimental tag still is on it for example. > As I said in another mail to this thread, applications have started to > poke in procfs to see whether they can use DAX or not. And what are they actually doing with that? > > Party A has promised party B We have never promised anyone anything. > So technically e1fb4a086495 is a user visible regression and in the > past we have reverted patches introducing these, even if the patch is > generally correct and poking in /proc/self/smaps is a bad idea. What actually stops working here and why? If some stupid app doesn't work without mixedmap and we want to apply the don't break userspace mantra hard we should just always expose it. > I just wanted to give them a documented way to check for this > promise. Being neutral if this promise is right or wrong, good or bad, > or whatever. That's not my call, but I prefer not having angry users, > yelling at me because of broken applications. There is no promise, sorry. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: Johannes Thumshirn <jthumshirn@suse.de> Cc: Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, mhocko@suse.cz, Dan Williams <dan.j.williams@intel.com> Subject: Re: Problems with VM_MIXEDMAP removal from /proc/<pid>/smaps Date: Tue, 2 Oct 2018 08:06:34 -0700 [thread overview] Message-ID: <20181002150634.GA22209@infradead.org> (raw) In-Reply-To: <20181002150123.GD4963@linux-x5ow.site> On Tue, Oct 02, 2018 at 05:01:24PM +0200, Johannes Thumshirn wrote: > On Tue, Oct 02, 2018 at 07:45:47AM -0700, Christoph Hellwig wrote: > > How does an application "make use of DAX"? What actual user visible > > semantics are associated with a file that has this flag set? > > There may not be any user visible semantics of DAX, but there are > promises we gave to application developers praising DAX as _the_ > method to map data on persistent memory and get around "the penalty of > the page cache" (however big this is). Who is "we"? As someone involved with DAX code I think it is a steaming pile of *****, and we are still looking for cases where it actually works without bugs. That's why the experimental tag still is on it for example. > As I said in another mail to this thread, applications have started to > poke in procfs to see whether they can use DAX or not. And what are they actually doing with that? > > Party A has promised party B We have never promised anyone anything. > So technically e1fb4a086495 is a user visible regression and in the > past we have reverted patches introducing these, even if the patch is > generally correct and poking in /proc/self/smaps is a bad idea. What actually stops working here and why? If some stupid app doesn't work without mixedmap and we want to apply the don't break userspace mantra hard we should just always expose it. > I just wanted to give them a documented way to check for this > promise. Being neutral if this promise is right or wrong, good or bad, > or whatever. That's not my call, but I prefer not having angry users, > yelling at me because of broken applications. There is no promise, sorry.
next prev parent reply other threads:[~2018-10-02 15:06 UTC|newest] Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-02 10:05 Problems with VM_MIXEDMAP removal from /proc/<pid>/smaps Jan Kara 2018-10-02 10:05 ` Jan Kara 2018-10-02 10:05 ` Jan Kara 2018-10-02 10:50 ` Michal Hocko 2018-10-02 10:50 ` Michal Hocko 2018-10-02 13:32 ` Jan Kara 2018-10-02 13:32 ` Jan Kara 2018-10-02 12:10 ` Johannes Thumshirn 2018-10-02 12:10 ` Johannes Thumshirn 2018-10-02 12:10 ` Johannes Thumshirn 2018-10-02 14:20 ` Johannes Thumshirn 2018-10-02 14:20 ` Johannes Thumshirn 2018-10-02 14:20 ` Johannes Thumshirn 2018-10-02 14:45 ` Christoph Hellwig 2018-10-02 14:45 ` Christoph Hellwig 2018-10-02 15:01 ` Johannes Thumshirn 2018-10-02 15:01 ` Johannes Thumshirn 2018-10-02 15:01 ` Johannes Thumshirn 2018-10-02 15:06 ` Christoph Hellwig [this message] 2018-10-02 15:06 ` Christoph Hellwig 2018-10-04 10:09 ` Johannes Thumshirn 2018-10-04 10:09 ` Johannes Thumshirn 2018-10-04 10:09 ` Johannes Thumshirn 2018-10-05 6:25 ` Christoph Hellwig 2018-10-05 6:25 ` Christoph Hellwig 2018-10-05 6:35 ` Johannes Thumshirn 2018-10-05 6:35 ` Johannes Thumshirn 2018-10-05 6:35 ` Johannes Thumshirn 2018-10-06 1:17 ` Dan Williams 2018-10-06 1:17 ` Dan Williams 2018-10-14 15:47 ` Dan Williams 2018-10-14 15:47 ` Dan Williams 2018-10-17 20:01 ` Dan Williams 2018-10-18 17:43 ` Jan Kara 2018-10-18 17:43 ` Jan Kara 2018-10-18 19:10 ` Dan Williams 2018-10-18 19:10 ` Dan Williams 2018-10-19 3:01 ` Dave Chinner 2018-10-19 3:01 ` Dave Chinner 2018-10-02 14:29 ` Jan Kara 2018-10-02 14:29 ` Jan Kara 2018-10-02 14:29 ` Jan Kara 2018-10-02 14:37 ` Christoph Hellwig 2018-10-02 14:37 ` Christoph Hellwig 2018-10-02 14:37 ` Christoph Hellwig 2018-10-02 14:44 ` Johannes Thumshirn 2018-10-02 14:44 ` Johannes Thumshirn 2018-10-02 14:44 ` Johannes Thumshirn 2018-10-02 14:44 ` Johannes Thumshirn 2018-10-02 14:44 ` Johannes Thumshirn 2018-10-02 14:52 ` Christoph Hellwig 2018-10-02 14:52 ` Christoph Hellwig 2018-10-02 14:52 ` Christoph Hellwig 2018-10-02 15:31 ` Jan Kara 2018-10-02 15:31 ` Jan Kara 2018-10-02 15:31 ` Jan Kara 2018-10-02 20:18 ` Dan Williams 2018-10-02 20:18 ` Dan Williams 2018-10-03 12:50 ` Jan Kara 2018-10-03 12:50 ` Jan Kara 2018-10-03 12:50 ` Jan Kara 2018-10-03 14:38 ` Dan Williams 2018-10-03 14:38 ` Dan Williams 2018-10-03 15:06 ` Jan Kara 2018-10-03 15:06 ` Jan Kara 2018-10-03 15:06 ` Jan Kara 2018-10-03 15:13 ` Dan Williams 2018-10-03 15:13 ` Dan Williams 2018-10-03 15:13 ` Dan Williams 2018-10-03 16:44 ` Jan Kara 2018-10-03 16:44 ` Jan Kara 2018-10-03 16:44 ` Jan Kara 2018-10-03 21:13 ` Dan Williams 2018-10-03 21:13 ` Dan Williams 2018-10-03 21:13 ` Dan Williams 2018-10-04 10:04 ` Johannes Thumshirn 2018-10-04 10:04 ` Johannes Thumshirn 2018-10-04 10:04 ` Johannes Thumshirn 2018-10-04 10:04 ` Johannes Thumshirn 2018-10-04 10:04 ` Johannes Thumshirn 2018-10-02 15:07 ` Jan Kara 2018-10-02 15:07 ` Jan Kara 2018-10-02 15:07 ` Jan Kara 2018-10-17 20:23 ` Jeff Moyer 2018-10-17 20:23 ` Jeff Moyer 2018-10-17 20:23 ` Jeff Moyer 2018-10-17 20:23 ` Jeff Moyer 2018-10-18 0:25 ` Dave Chinner 2018-10-18 0:25 ` Dave Chinner 2018-10-18 0:25 ` Dave Chinner 2018-10-18 14:55 ` Jan Kara 2018-10-18 14:55 ` Jan Kara 2018-10-19 0:43 ` Dave Chinner 2018-10-19 0:43 ` Dave Chinner 2018-10-19 0:43 ` Dave Chinner 2018-10-30 6:30 ` Dan Williams 2018-10-30 6:30 ` Dan Williams 2018-10-30 6:30 ` Dan Williams 2018-10-30 22:49 ` Dave Chinner 2018-10-30 22:49 ` Dave Chinner 2018-10-30 22:49 ` Dave Chinner 2018-10-30 22:59 ` Dan Williams 2018-10-30 22:59 ` Dan Williams 2018-10-30 22:59 ` Dan Williams 2018-10-31 5:59 ` y-goto 2018-10-31 5:59 ` y-goto-LMvhtfratI1BDgjK7y7TUQ 2018-10-31 5:59 ` y-goto 2018-11-01 23:00 ` Dave Chinner 2018-11-01 23:00 ` Dave Chinner 2018-11-01 23:00 ` Dave Chinner 2018-11-02 1:43 ` y-goto 2018-11-02 1:43 ` y-goto-LMvhtfratI1BDgjK7y7TUQ 2018-11-02 1:43 ` y-goto 2018-10-18 21:05 ` Jeff Moyer 2018-10-18 21:05 ` Jeff Moyer 2018-10-18 21:05 ` Jeff Moyer 2018-10-18 21:05 ` Jeff Moyer 2018-10-09 19:43 ` Jeff Moyer 2018-10-09 19:43 ` Jeff Moyer 2018-10-09 19:43 ` Jeff Moyer 2018-10-16 8:25 ` Jan Kara 2018-10-16 8:25 ` Jan Kara 2018-10-16 12:35 ` Jeff Moyer 2018-10-16 12:35 ` Jeff Moyer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181002150634.GA22209@infradead.org \ --to=hch@infradead.org \ --cc=jack@suse.cz \ --cc=jthumshirn@suse.de \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=mhocko@suse.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.