From: Matthew Wilcox <willy@linux.intel.com>
To: "Zuckerman, Boris" <borisz@hp.com>
Cc: Vladislav Bolkhovitin <vst@vlnb.net>,
"rob.gittins@linux.intel.com" <rob.gittins@linux.intel.com>,
"linux-pmfs@lists.infradead.org" <linux-pmfs@lists.infradead.org>,
"linux-fsdevel@veger.org" <linux-fsdevel@veger.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs
Date: Thu, 26 Sep 2013 13:56:24 -0400 [thread overview]
Message-ID: <20130926175624.GA7422@linux.intel.com> (raw)
In-Reply-To: <4C30833E5CDF444D84D942543DF65BDA58066A30@G9W0739.americas.hpqcorp.net>
On Thu, Sep 26, 2013 at 02:56:17PM +0000, Zuckerman, Boris wrote:
> To work with persistent memory as efficiently as we can work with RAM we need a bit more than "commit". It's reasonable to expect that we get some additional support from CPUs that goes beyond mfence and mflush. That may include discovery, transactional support, etc. Encapsulating that in a special class sooner than later seams a right thing to do...
If it's something CPU-specific, then we wouldn't handle it as part of
the "class", we'd handle it as an architecture abstraction. It's only
operations which are device-specific which would need to be exposed
through an operations vector. For example, suppose you buy one device
from IBM and another device from HP, and plug them both into your SPARC
system. The code you compile needs to run on SPARC, doing whatever
CPU operations are supported, but if HP and IBM have different ways of
handling a "commit" operation, we need that operation to be part of an
operations vector.
next prev parent reply other threads:[~2013-09-26 17:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-04 21:54 RFC Block Layer Extensions to Support NV-DIMMs Rob Gittins
2013-09-05 12:12 ` Jeff Moyer
2013-09-05 15:34 ` Matthew Wilcox
2013-09-05 17:15 ` Jeff Moyer
2013-09-05 17:57 ` Matthew Wilcox
2013-09-05 19:46 ` Zuckerman, Boris
2013-09-05 20:43 ` Gittins, Rob
2013-09-05 21:02 ` Zuckerman, Boris
2013-09-05 16:33 ` Rob Gittins
2013-09-05 17:19 ` Jeff Moyer
2013-09-07 5:12 ` Vladislav Bolkhovitin
2013-09-23 22:51 ` Rob Gittins
2013-09-26 6:58 ` Vladislav Bolkhovitin
2013-09-26 14:56 ` Zuckerman, Boris
2013-09-26 17:56 ` Matthew Wilcox [this message]
2013-09-26 19:36 ` Zuckerman, Boris
2013-09-28 7:44 ` Vladislav Bolkhovitin
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=20130926175624.GA7422@linux.intel.com \
--to=willy@linux.intel.com \
--cc=borisz@hp.com \
--cc=linux-fsdevel@veger.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pmfs@lists.infradead.org \
--cc=rob.gittins@linux.intel.com \
--cc=vst@vlnb.net \
/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