From: Benjamin LaHaise <bcrl@kvack.org>
To: Vyacheslav Dubeyko <slava@dubeyko.com>
Cc: Matthew Wilcox <willy@linux.intel.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: NVM Mapping API
Date: Wed, 16 May 2012 17:58:49 -0400 [thread overview]
Message-ID: <20120516215849.GC32221@kvack.org> (raw)
In-Reply-To: <1337149453.1961.24.camel@slavad-ubuntu-11>
On Wed, May 16, 2012 at 10:24:13AM +0400, Vyacheslav Dubeyko wrote:
> Could you please share vision of these NVM technologies in more details?
> What capacity in bytes of of one NVM unit do we can expect? What about
> bad blocks and any other reliability issues of such NVM technologies?
>
> I think that some more deep understanding of this can give possibility
> to imagine more deeply possible niche of such NVM units in future memory
> subsystem architecture.
Try having a look at the various articles on ReRAM, PRAM, FeRAM, MRAM...
There are a number of technologies being actively developed. For some
quick info, Samsung has presented data on an 8Gbit 20nm device (see
http://www.eetimes.com/electronics-news/4230958/ISSCC--Samsung-preps-8-Gbit-phase-change-memory ).
It's hard to predict who will be first to market with a real production
volume product, though.
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.
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.
-ben
next prev parent reply other threads:[~2012-05-16 21:58 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 [this message]
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
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=20120516215849.GC32221@kvack.org \
--to=bcrl@kvack.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).