From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [Lsf-pc] [LSF/MM ATTEND] persistent transparent large Date: Wed, 29 Jan 2014 15:00:40 -0800 Message-ID: <1391036440.2181.52.camel@dabdike.int.hansenpartnership.com> References: <20140128193833.GD20939@parisc-linux.org> <1390943052.16253.31.camel@dabdike> <20140129023903.GF20939@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Cc: Hugh Dickins , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org To: Matthew Wilcox Return-path: In-Reply-To: <20140129023903.GF20939@parisc-linux.org> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2014-01-28 at 19:39 -0700, Matthew Wilcox wrote: > On Tue, Jan 28, 2014 at 01:04:12PM -0800, James Bottomley wrote: > > That rather depends on whether you think Execute In Place is the correct > > way to handle persistent memory, I think? I fully accept that it looks > > like a good place to start since it's how all embedded systems handle > > flash ... although looking at the proliferation of XIP hacks and > > filesystems certainly doesn't give one confidence that they actually got > > it right. > > One of the things I don't like about the current patch is that XIP > has two completely unrelated meanings. The embedded people use it > for eXecuting the kernel in-place, whereas the CONFIG_FS_XIP code is > all about avoiding the page cache (for both executables and data). > I'd love to rename it to prevent this confusion ... I just have no idea > what to call it. Somebody suggested Map In Place (MIP). Maybe MAXIP > (Map And eXecute In Place)? I'd rather something that was a TLA though. I understand; essentially it's about inserting existing pages into the page cache as mappings. Curiously it's not unlike one of the user space APIs the database people have requested. > > Fixing XIP looks like a good thing independent of whether it's the right > > approach for persistent memory. However, one thing that's missing for > > the current patch sets is any buy in from the existing users ... can > > they be persuaded to drop their hacks and adopt it (possibly even losing > > some of the XIP specific filesystems), or will this end up as yet > > another XIP hack? > > There's only one in-tree filesystem using the current interfaces (ext2) > and it's converted as part of the patchset. And there're only three > devices drivers implementing the current interface (dcssblk, axonram > and brd). The MTD XIP is completely unrelated to this, and doesn't need > to be converted. Quite a few of the MTD XIP patches have been *application* not kernel; those should be convertible to your patches. > > Then there's the meta problem of is XIP the right approach. Using > > persistence within the current memory address space as XIP is a natural > > fit for mixed volatile/NV systems, but what happens when they're all NV > > memory? Should we be discussing some VM based handling mechanisms for > > persistent memory? > > I think this discussion would be more related to checkpointing than it > is VM, so we probably wouldn't have the right people in the room for that. > It would probably have been a good discussion to have at kernel summit. Actually, since all the checkpointing guys are mad russians and mostly happen to work for Parallels I can see whom I can provide (I was planning to poke them with a big stick to attend, anyway). James -- 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