Dave Chinner wrote:
On Mon, Jan 20, 2014 at 11:38:16PM -0800, Howard Chu wrote:
Andy Lutomirski wrote:
On 01/16/2014 08:17 PM, Howard Chu wrote:
Andy Lutomirski wrote:
I'm interested in a persistent memory track. There seems to be plenty
of other emails about this, but here's my take:
I'm also interested in this track. I'm not up on FS development these
days, the last time I wrote filesystem code was nearly 20 years ago. But
persistent memory is a topic near and dear to my heart, and of great
relevance to my current pet project, the LMDB memory-mapped database.
In a previous era I also developed block device drivers for
battery-backed external DRAM disks. (My ideal would have been systems
where all of RAM was persistent. I suppose we can just about get there
with mobile phones and tablets these days.)
In the context of database engines, I'm interested in leveraging
persistent memory for write-back caching and how user level code can be
made aware of it. (If all your cache is persistent and guaranteed to
eventually reach stable store then you never need to fsync() a
transaction.)
I don't think that is true - your still going to need fsync to get
the CPU to flush it's caches and filesystem metadata into the
persistent domain....
Hmm. Presumably that would work by actually allocating cache pages in
persistent memory. I don't think that anything like the current XIP
interfaces can do that, but it's certainly an interesting thought for
(complicated) future work.
This might not be pretty in conjunction with something like my
writethrough mapping idea -- read(2) and write(2) would be fine (well,
write(2) might need to use streaming loads), but mmap users who weren't
expecting it might have truly awful performance. That especially
includes things like databases that aren't expecting this behavior.
At the moment all I can suggest is a new mmap() flag, e.g.
MAP_PERSISTENT. Not sure how a user or app should discover that it's
supported though.
The point of using the XIP interface with filesystems that are
backed by persistent memory is that mmap() gives userspace
applications direct acess to the persistent memory directly without
needing any modifications. It's just a really, really fast file...
OK, I see that now. But that only works well when your persistent memory size
is >= the size of the file(s) you want to work with.
If you use persistent memory for the page cache, then you can use it with any
filesystem of any arbitrary size.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
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
