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