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