Re: virtual memory
- From: "robertwessel2@xxxxxxxxx" <robertwessel2@xxxxxxxxx>
- Date: 30 May 2006 22:37:52 -0700
David Kanter wrote:
It seems to me that using flash as a replacement for HDs is unrealistic
due to cost issues except for really peculiar situations. The
advantages of flash over a disk are very fast random R/W. A disk could
actually outperform solid state for sequential reads/writes, and be
cheaper to boot. Flash has the disadvantage that there is a limited
number of writes/device. So, ideally, what you want to do is profile
your VM, and see if a region of memory is being randomly accessed a
lot. Then you migrate that part from disk to flash and leave it there
till you end up with a different 'hot spot'.
It would be much better to just add the same amount of DRAM to the
system rather than page to flash. If the OS can identify which pages
should go to the "fast" paging device, it can certainly decide to keep
those pages in (the extra) RAM in the first place.
Again, that assumes there isn't some reason why you can't add DRAM to
the system.
Some applications like DMBS might be able to figure out that certain
areas are going to be 'hot' (perhaps the index of your database), but
other applications really won't have a clue. So you need both
application specified migration and some sort of seamless OS controlled
migration policy AND you need to have a good mechanism for choosing
when the OS overrides apps and vica versa.
Fast external NV storage (aka SSDs - solid-state-disk) does have some
applications. Database indexes are one. *But,* a modest sized NV
write buffer for the disk subsystem plus enough extra RAM to cache the
index is likely to be a better solution in most cases, if a tiny bit
more expensive (in raw parts cost - it may well be cheaper from a
system perspective). It is also a much more generally useful solution.
Now if your index has very heavy write traffic, then an SSD type of
solution actually makes some sense, but flash SSDs in particular are
poorly suited because of the write issues (most SSD vendors do
something like a battery backed DRAMs with a disk for dumping the RAM
contents at shutdown). Conversely, just increasing the size of the NV
write buffer will do more-or-less the same thing (along with the extra
system RAM), and again have the benefit of being general solutions
(admittedly at about twice the memory cost).
A fast flash disk to hold commonly used files (or portions thereof)
makes sense on the surface, since it improves first access times too.
But if you have some way to identify what data is "hot", you can just
reorg the disk so that the hot data is in one sequential spot, and then
just read all of that into a RAM disk at system startup (or use that to
prime the cache). Of course in the case of a database index first use
is something of a non-issue since these things tend to stay up for
extended periods of time.
None of this is to say that various combinations of systems, OSs, and
applications might not benefit from an SSD (and sometimes in a big
way), but it's almost always because those parts are limited in some
way (eg. you can't fit more RAM into the system), and not because SSDs
are a good idea in general. This is similar to EMS memory back in the
DOS days - nobody would ever claim that EMS was a good idea, but
limitations of the real mode x86 and DOS made it a solution for a
number of important problem, if a rather ugly one. And as soon as
vendors were able to rewrite their applications to run in a protected
mode system, all that EMS/EEMS/XMS stuff went mercifully away.
A slightly interesting counterexample is the MS-and-some-drive-vendor
initiative to build a merged disk/flash device. But there the main
interest is power savings (on the assumption that many reqeuests will
be satisfied from the flash, which will allow the hard disk to be shut
down more of the time), and not performance. Boot performance might
improve if the boot can run almost entierly from the flash, but you'll
take a huge hit when you do have to access the shut down disk. Again,
the question is why not just keep all of the stuff you'd put on the
flash part of the flask/disk hybrid in main memory (again with a modest
sized NV write buffer on the drive).
.
- References:
- virtual memory
- From: khan
- Re: virtual memory
- From: rambam
- Re: virtual memory
- From: Bernd Paysan
- Re: virtual memory
- From: robertwessel2@xxxxxxxxx
- Re: virtual memory
- From: David Kanter
- virtual memory
- Prev by Date: Re: virtual memory
- Next by Date: Re: Block diagrams for NVAX, Rigel/Mariah, VAX 9000 wanted
- Previous by thread: Re: virtual memory
- Next by thread: Re: virtual memory
- Index(es):
Relevant Pages
|
