Re: [Lsf-pc] [LSF/MM ATTEND] persistent transparent large

[Matthew Wilcox <matthew@wil.cx>]

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.

> 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.

> 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.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>