lkml.org 
[lkml]   [2015]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: "Directly mapped persistent memory page cache"

* Zuckerman, Boris <borisz@hp.com> wrote:

> Hi,
>
> Data transformation (EC, encryption, etc) is commonly done by
> storage systems today. [...]

That's a strawman argument: if you do encryption/compression in the
storage space then you don't need complex struct page descriptors for
the storage space: as the resulting content won't be mappable nor
DMA-able into from high level APIs...

My proposal adds a RAM-integrated usage model for devices that are
directly mapped in physical RAM space (such as persistent memory),
where integration with high level Linux APIs is possible and
desirable.

If pmem is used as a front-side cache for a larger storage system
behind, then the disk side can still be encrypted/compressed/etc.

( Also note that if the pmem hardware itself adds an encryption pass
then actual stored content might still be encrypted. )

> [...] But let's think about other less common existing and PM
> specific upcoming features like data sharing between multiple
> consumers (computers for example), [...]

RDMA should work fine if the pmem hardware exposes it.

> [...] support for atomicity (to avoid journaling in PM space), etc.

This too should work fine, by way of the SMP coherency protocol, if
atomic instructions are used on the relevant metadata.

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-05-11 13:01    [W:0.169 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site