User: Password:
|
|
Subscribe / Log in / New account

Re: NVM Mapping API

From:  Matthew Wilcox <willy-AT-linux.intel.com>
To:  Benjamin LaHaise <bcrl-AT-kvack.org>
Subject:  Re: NVM Mapping API
Date:  Thu, 17 May 2012 15:06:18 -0400
Message-ID:  <20120517190618.GQ22985@linux.intel.com>
Cc:  Vyacheslav Dubeyko <slava-AT-dubeyko.com>, linux-fsdevel-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org
Archive-link:  Article

On Wed, May 16, 2012 at 05:58:49PM -0400, Benjamin LaHaise wrote:
> The big question I have is what the actual interface for these types of 
> memory will be.  If they're like actual RAM and can be mmap()ed into user 
> space, it will be preferable to avoid as much of the overhead of the existing 
> block infrastructure that most current day filesystems are built on top of.  

Yes.  I'm hoping that filesystem developers will indicate enthusiasm
for moving to new APIs.  If not the ones I've proposed, then at least
ones which can be implemented more efficiently with a device that looks
like DRAM.

> If the devices have only modest endurance limits, we may need to stick the 
> kernel in the middle to prevent malicious code from wearing out a user's 
> memory cells.

Yes, or if the device has long write latencies or poor write bandwidth,
we'll also want to buffer writes in DRAM.  My theory is that this is
doable transparently to the user; we can map it read-only, and handle
the fault by copying from NVM to DRAM, then changing the mapping and
restarting the instruction.  The page would be written back to NVM on
a sync call, or when memory pressure or elapsed time dictates.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



(Log in to post comments)


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds