From: Arnd Bergmann <arnd@arndb.de>
To: Matthew Wilcox <willy@linux.intel.com>, Carsten Otte <cotte@de.ibm.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: NVM Mapping API
Date: Fri, 18 May 2012 09:33:49 +0000 [thread overview]
Message-ID: <201205180933.49516.arnd@arndb.de> (raw)
In-Reply-To: <20120515133450.GD22985@linux.intel.com>
On Tuesday 15 May 2012, Matthew Wilcox wrote:
>
> There are a number of interesting non-volatile memory (NVM) technologies
> being developed. Some of them promise DRAM-comparable latencies and
> bandwidths. At Intel, we've been thinking about various ways to present
> those to software. This is a first draft of an API that supports the
> operations we see as necessary. Patches can follow easily enough once
> we've settled on an API.
>
> We think the appropriate way to present directly addressable NVM to
> in-kernel users is through a filesystem. Different technologies may want
> to use different filesystems, or maybe some forms of directly addressable
> NVM will want to use the same filesystem as each other.
ext2 actually supports some of this already with mm/filemap_xip.c, Carsten
Otte introduced it initially to support drivers/s390/block/dcssblk.c with
execute-in-place, so you don't have to copy around the data when your
block device is mapped into the physical address space already.
I guess this could be implemented in modern file systems (ext4, btrfs)
as well, or you could have a new simple fs on top of the same base API.
(ext2+xip was originally a new file system but then merged into ext2).
Also note that you could easily implement non-volatile memory in other
virtual machines doing the same thing that dcssblk does: E.g. in KVM
you would only need to map a host file into the guess address space
and let the guest take advantage of a similar feature set that you
get from the new memory technologies in real hardware.
Arnd
prev parent reply other threads:[~2012-05-18 9:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 13:34 NVM Mapping API Matthew Wilcox
2012-05-15 17:46 ` Greg KH
2012-05-16 15:57 ` Matthew Wilcox
2012-05-18 12:07 ` Marco Stornelli
2012-05-15 23:02 ` Andy Lutomirski
2012-05-16 16:02 ` Matthew Wilcox
2012-05-31 17:53 ` Andy Lutomirski
2012-05-16 6:24 ` Vyacheslav Dubeyko
2012-05-16 16:10 ` Matthew Wilcox
2012-05-17 9:06 ` Vyacheslav Dubeyko
2012-05-16 21:58 ` Benjamin LaHaise
2012-05-17 19:06 ` Matthew Wilcox
2012-05-16 9:52 ` James Bottomley
2012-05-16 17:35 ` Matthew Wilcox
2012-05-16 19:58 ` Christian Stroetmann
2012-05-19 22:19 ` Christian Stroetmann
2012-05-17 9:54 ` James Bottomley
2012-05-17 18:59 ` Matthew Wilcox
2012-05-18 9:03 ` James Bottomley
2012-05-18 10:13 ` Boaz Harrosh
2012-05-18 14:49 ` Matthew Wilcox
2012-05-18 15:08 ` Alan Cox
2012-05-18 15:31 ` James Bottomley
2012-05-18 17:19 ` Matthew Wilcox
2012-05-16 13:04 ` Boaz Harrosh
2012-05-16 18:33 ` Matthew Wilcox
2012-05-18 9:33 ` Arnd Bergmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201205180933.49516.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=cotte@de.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.