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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
