[LSF/MM ATTEND] persistent transparent large

[LSF/MM ATTEND] persistent transparent large

[Hugh Dickins]

I'm eager to participate in this year's LSF/MM, but no topics of my
own to propose: I need to listen to what other people are suggesting.

Topics of most interest to me span mm and fs: persistent memory and
xip, transparent huge pagecache, large sectors, mm scalability.
Volatile ranges, memcg lowlimits, those should be on the list too.

Plus I'm concerned at the way mm is now exploding: how to handle the
volume.  I hope most of the useful new contributors to mm can be there.

Hugh

Re: [LSF/MM ATTEND] persistent transparent large

[Matthew Wilcox]

On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote:
> I'm eager to participate in this year's LSF/MM, but no topics of my
> own to propose: I need to listen to what other people are suggesting.
> 
> Topics of most interest to me span mm and fs: persistent memory and
> xip, transparent huge pagecache, large sectors, mm scalability.

I don't want to particularly pick on Hugh here; indeed, I know he won't
take it personally which is why I've chosen to respoond to Hugh's message
rather than any of the others.  I'm rather annoyed at the huge disrepancy
between the number of people who are *saying* they're interested in
persistent memory and the number of people who are reviewing patches
relating to persistent memory.

As far as I'm concerned, the only people who have "earned" their way into
attending the Summit based on contributing to persistent memory work
would be Dave Chinner (er ... on the ctte already), Ted Ts'o (ditto),
Jan Kara (ditto), Kirill Shutemov, Dave Hansen (who's not looking to
attend this year), Ross Zwisler (ditto), and Andreas Dilger.

I'd particularly like a VM person to review these two patches:

http://marc.info/?l=linux-fsdevel&m=138983598101510&w=2
http://marc.info/?l=linux-fsdevel&m=138983600001513&w=2

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

Re: [LSF/MM ATTEND] persistent transparent large

[Hugh Dickins]

On Tue, 28 Jan 2014, Matthew Wilcox wrote:
> On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote:
> > I'm eager to participate in this year's LSF/MM, but no topics of my
> > own to propose: I need to listen to what other people are suggesting.
> > 
> > Topics of most interest to me span mm and fs: persistent memory and
> > xip, transparent huge pagecache, large sectors, mm scalability.
> 
> I don't want to particularly pick on Hugh here; indeed, I know he won't
> take it personally which is why I've chosen to respoond to Hugh's message

Sure, your remarks are completely appropriate, and very well directed.

> rather than any of the others.  I'm rather annoyed at the huge disrepancy
> between the number of people who are *saying* they're interested in
> persistent memory and the number of people who are reviewing patches
> relating to persistent memory.

It's fair enough, though, for people to express an interest in a topic,
without having time to contribute to it beforehand.  That does not earn
anyone a place, but may help the committee to choose between topics.

Frustrating for you, though; and for everyone else pushing a patchset.

> 
> As far as I'm concerned, the only people who have "earned" their way into
> attending the Summit based on contributing to persistent memory work
> would be Dave Chinner (er ... on the ctte already), Ted Ts'o (ditto),
> Jan Kara (ditto), Kirill Shutemov, Dave Hansen (who's not looking to
> attend this year), Ross Zwisler (ditto), and Andreas Dilger.

It might be a good idea to insist on significant review contributions
in relevant areas as a condition for attendance.  That's a matter for
the committee to decide (I expect it's already taken into account),
but it should help to improve our review rate.

Counts me out, but that's okay.

> 
> I'd particularly like a VM person to review these two patches:
> 
> http://marc.info/?l=linux-fsdevel&m=138983598101510&w=2
> http://marc.info/?l=linux-fsdevel&m=138983600001513&w=2

I'd love to give you a constructive answer, but I'm not going to
comment on 2 out of 22 without getting to grips with the 22.  You've
been thinking about this stuff for months: others need time too,
and this is far from the only patchset on their queues.

Hugh

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

Re: [LSF/MM ATTEND] persistent transparent large

[Matthew Wilcox]

On Tue, Jan 28, 2014 at 12:42:08PM -0800, Hugh Dickins wrote:
> On Tue, 28 Jan 2014, Matthew Wilcox wrote:
> > On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote:
> > > I'm eager to participate in this year's LSF/MM, but no topics of my
> > > own to propose: I need to listen to what other people are suggesting.
> > > 
> > > Topics of most interest to me span mm and fs: persistent memory and
> > > xip, transparent huge pagecache, large sectors, mm scalability.
> > 
> > I don't want to particularly pick on Hugh here; indeed, I know he won't
> > take it personally which is why I've chosen to respoond to Hugh's message
> 
> Sure, your remarks are completely appropriate, and very well directed.

Thanks.  You're a long-time contributor in so many ways to the VM that I
know this won't prejudice the program committee against you.

> > rather than any of the others.  I'm rather annoyed at the huge disrepancy
> > between the number of people who are *saying* they're interested in
> > persistent memory and the number of people who are reviewing patches
> > relating to persistent memory.
> 
> It's fair enough, though, for people to express an interest in a topic,
> without having time to contribute to it beforehand.  That does not earn
> anyone a place, but may help the committee to choose between topics.

Absolutely.  And it might help convince the program committee to invite
someone if they were seen to be active ... ;-)

> > I'd particularly like a VM person to review these two patches:
> > 
> > http://marc.info/?l=linux-fsdevel&m=138983598101510&w=2
> > http://marc.info/?l=linux-fsdevel&m=138983600001513&w=2
> 
> I'd love to give you a constructive answer, but I'm not going to
> comment on 2 out of 22 without getting to grips with the 22.  You've
> been thinking about this stuff for months: others need time too,
> and this is far from the only patchset on their queues.

The first one is stand-alone.  It fixes a bug that has been around for
years ... but nobody noticed because nobody uses XIP.

The second is a little more involved with the rest of the patchset,
and I'd totally understand anyone wanting to review it in conjunction
with the rest of the patchset.

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

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

[James Bottomley]

On Tue, 2014-01-28 at 12:38 -0700, Matthew Wilcox wrote:
> On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote:
> > I'm eager to participate in this year's LSF/MM, but no topics of my
> > own to propose: I need to listen to what other people are suggesting.
> > 
> > Topics of most interest to me span mm and fs: persistent memory and
> > xip, transparent huge pagecache, large sectors, mm scalability.
> 
> I don't want to particularly pick on Hugh here; indeed, I know he won't
> take it personally which is why I've chosen to respoond to Hugh's message
> rather than any of the others.  I'm rather annoyed at the huge disrepancy
> between the number of people who are *saying* they're interested in
> persistent memory and the number of people who are reviewing patches
> relating to persistent memory.
> 
> As far as I'm concerned, the only people who have "earned" their way into
> attending the Summit based on contributing to persistent memory work
> would be Dave Chinner (er ... on the ctte already), Ted Ts'o (ditto),
> Jan Kara (ditto), Kirill Shutemov, Dave Hansen (who's not looking to
> attend this year), Ross Zwisler (ditto), and Andreas Dilger.

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.

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?

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?

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

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

[Hugh Dickins]

On Tue, 28 Jan 2014, James Bottomley wrote:
> 
> 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?

Yes (but at present there's nothing on the table: is the cupboard bare?)

Sorry, answer devoid of content, but since it's my thread...

Hugh

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

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

[Matthew Wilcox]

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>

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

[James Bottomley]

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