linux-kernel - RE: RFC Block Layer Extensions to Support NV-DIMMs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C30833E5CDF444D84D942543DF65BDA580690B7@G9W0739.americas.hpqcorp.net>
Date:	Thu, 26 Sep 2013 19:36:14 +0000
From:	"Zuckerman, Boris" <borisz@...com>
To:	Matthew Wilcox <willy@...ux.intel.com>
CC:	Vladislav Bolkhovitin <vst@...b.net>,
	"rob.gittins@...ux.intel.com" <rob.gittins@...ux.intel.com>,
	"linux-pmfs@...ts.infradead.org" <linux-pmfs@...ts.infradead.org>,
	"linux-fsdevel@...er.org" <linux-fsdevel@...er.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: RFC Block Layer Extensions to Support NV-DIMMs

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@...ux.intel.com]
> Sent: Thursday, September 26, 2013 1:56 PM
> To: Zuckerman, Boris
> Cc: Vladislav Bolkhovitin; rob.gittins@...ux.intel.com; linux-pmfs@...ts.infradead.org;
> linux-fsdevel@...er.org; linux-kernel@...r.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/