Date: Sun, 8 May 2016 14:16:56 +0300 From: Lev Serebryakov <lev@FreeBSD.org> To: Matthew Seaman <matthew@FreeBSD.org>, freebsd-fs@freebsd.org Subject: Re: Fwd: The Morning Paper: NOVA - A log-structured file system for hybrid volatile/non-volatile main memories Message-ID: <1799639504.20160508141650@serebryakov.spb.ru> In-Reply-To: <d88a8502-3db5-5a93-c0c9-21e35054e334@FreeBSD.org> References: <4188b6afbe9e5d43111fef4d4ae5e599a57.20160506051425@mail23.atl91.mcsv.net> <2BE88161-D83A-4265-9EC3-C2F7F7033E93@neville-neil.com> <59877.1462639101@critter.freebsd.dk> <07228891.20160508134321@serebryakov.spb.ru> <d88a8502-3db5-5a93-c0c9-21e35054e334@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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@FreeBSD.org [-- Attachment #2 --] -----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJXLyAoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePNOcQAN1djkHRHiT2W6psCFPJnGUQ LSnNjM9ZuF1uByQXFnjmoAmwUJZR6MI1SIntytPpuhgzdv8UW+zeXtMIijyfVAZ4 sW7Mb2BB6FmTYfZ//JIt5hxL24DCo76U3ftA6Y01/DNEO1bPo4GHAXaBXXj0191P Ch2eeVsVY40AVhN2VsHdZ9xZebsvyPFQmOZH1hmn+558RmUIdgifVGddaPG5JT4P PDyTG6YXVXN9F6xgCPHeAnCARb6otHKH5/FUuftpL6bWhlGT3LViU8LeZajqacmI nQy52FuQU0TjAEtsu3kCQk1IrMgEMKJa9hTuI+HO/0ktQybzePsE9WVpJq9EFof2 Ge98RSEM+2vctMaa4ZR8D2NutbZkD0GGo+tUzcQqvO42PKk2ZEH1b3utfuRLOMqJ jEWxYsICznOvUnB1C7GrFJ7l0GF0DQhTXKYAwPf7df2B5oqp5qdChphtxbSJG7p7 fHOdgaD9R0Oaovs93mXvh6CJnNKy06RUjJiOQBfPfvUeHgCFwIxFVlgpH+pzm0Fs wgqwOXExw20Uuy+3UrHoi6zsabesjsGk6q8SHavR+TiNCXwzyl/e1y7qZUjzeY2y st90y7iKcEkeoUkgte1qhL6zlh2dit1deQ1AJOkPDxKRLWei2eouV00pujgAf72Q ah9rtn3Ps6APCyIQsQGw =oRi8 -----END PGP MESSAGE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1799639504.20160508141650>