lkml.org 
[lkml]   [2013]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: RFC Block Layer Extensions to Support NV-DIMMs
Date
I assume that we may have both: CPUs that may have ability to support multiple transactions, CPUs that support only one, CPUs that support none (as today), as well as different devices - transaction capable and not.
So, it seems there is a room for compilers to do their work and for class drivers to do their, right?

boris

> -----Original Message-----
> From: Matthew Wilcox [mailto:willy@linux.intel.com]
> Sent: Thursday, September 26, 2013 1:56 PM
> To: Zuckerman, Boris
> Cc: Vladislav Bolkhovitin; rob.gittins@linux.intel.com; linux-pmfs@lists.infradead.org;
> linux-fsdevel@veger.org; linux-kernel@vger.kernel.org
> Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs
>
> 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.


\
 
 \ /
  Last update: 2013-09-26 22:01    [W:0.061 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site