Fwd: The Morning Paper: NOVA - A log-structured file system for hybrid volatile/non-volatile main memories

Lev Serebryakov lev at FreeBSD.org
Sun May 8 11:17:03 UTC 2016


Hello Matthew,

Sunday, May 8, 2016, 1:56:00 PM, you wrote:

>>    Do you consider new Intel NVM "3D XPoint" technology? They(tm) promise
>>  prices lower than DRAM, but higher than SSD. And same for speed. Looks
>>  like, there will be THREE layers of NVM in near future: very large and slow
>>  (HDD, iSCSI/FC attached "shelf", things like this, multiterabyte), SSD
>>  (in 1-10 terabyte range) and this XPoint in current SSD range.
> 3D X-Point is only something like a factor of 30x slower than current
> DRAM modules (which is to say thousands of times faster than existing
> Flash modules), and I believe Intel are planning on selling it packaged
> as DIMMs as well as PCIx NVME devices.
   "only 30x slower" is not "only". "Memory is a new disk" is very mantra of
 high-performance programming, and additional "30x slower" is a killer,
 really. You will need to have DRAM-memory cache anywhere, or your CPU will
 wait for I/O forever. And sizes will not be such big to store all data in
 this memory, too.

  So, IMHO, it is still hierarchy of (persistent) caches -- non-persistent
 RAM, very fast new NVRAM, fast block device (SSD), etc.

  And this memory in DIMM form-factor is very different story. Allocating
 pages for stack, data, code of "ordinary" processes (and kernel needs) on
 it because it is in common RAM address space? Ridiculous. It is slow, it is
 valuable and all "generic" allocations in VM (all allocations we have
 today!) doesn't belong to it for sure. What would we do? I don't know. OSes
 need new API for databases and such to give them access to this memory, it
 doesn't look like current "this is heap" and "this is filesystem"
 abstractions work well here.

-- 
Best regards,
 Lev                            mailto:lev at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 960 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160508/ff823815/attachment.sig>


More information about the freebsd-fs mailing list