Comment by cowmixtoo | Hacker News Reader

Comment by cowmixtoo | Hacker News Reader

Parent Full thread

I have a lot of personal success stories with SSDs but here's my current favorite.

A few months ago I had to help one of our scientists (the company is called 5AM Solutions.. they the awesome) run a bioinformatic job written in Perl and R. As it turned out, for long stretches of the processing the job required around 20 GB of memory. The one server that had all the required dependencies installed had only 8 GB at the time.

When I let the job run the first time, it started to page out memory to hard disk. The job ran for about four days, was only about 25% complete and during that time frame the server was un-useable for any other functions. Pretty much everything came to grinding halt.

Between that first run and the time our new RAM would be installed, just for grins, I gave the system 30 GB of swap space on the locally attached SSD. With that configuration the job finished in 19 hours and during that time the server was still responsive of other tasks.

When we finally added the appropriate amount of physical RAM the job took only 15 hours to complete.

It is the first time I have ever seen virtual memory be useful.

"Virtual memory" is not a synonym for swap space: http://en.wikipedia.org/wiki/Virtual_memory

Virtual memory is what lets us write programs pretending that we own the entire address space, and it is very useful.

Swapping pages to disk, though, has been useful for a very long time. Yes, once your high-performance application starts swapping all the time, your performance is going to suffer by several orders of magnitude. But occasionally swapping pages in and out of disk is part of what makes modern operating systems useful. You left a large PowerPoint presentation open for several days, but never got around to working on it? Not a problem, since if the OS needs that memory, it will just swap out the pages. Without that ability, the OS would need to go around killing processes. (Which it will do if it has to, but it's a rare event because it can swap out pages.)

My point was that my application needed 166% more phyical memory than what I had at the time.

Paging out to a normal "disk" was not even an option, the performance ranged incredibly horrible to completely unusable.

Paging out to SSD was not only usable, it was only a percentage slower than 'real' RAM.

I think that's amazing. Having the option to use SSD as memory in a pinch is a great 'win'.

Hmm... I still think its valid to interchangeably use "Virtual memory" and swap space. Swap space is just where your "virtual memory" lives, right?

On modern systems, there are two kinds of addresses. "Virtual" addresses and physical addresses. Virtual addresses are tracked by the operating system, and they can span the entirety of the addressable address space. So, on a 32-bit system that isn't playing any high-memory tricks, that's 0 - 2^32, or 0 - 4 GB.

But your system may not have 4 GB. So the operating system has a data structure called a page table that has the virtual to physical mapping for each process. The processor accesses this table (it caches it in something called a TLB) so that it can convert the virtual address to the physical address.

An example using small numbers. Your program has a pointer to data. That pointer may have value 800. Let's assume that the amount of memory on your system is only between 0 - 400. So the processor has to convert the value 800 to a value between 0 - 400. It's the operating system's job to maintain that valid mapping.

Why does this matter, and why is it so tied up with paging to and from disk? Let's say the OS pages out the page containing that data. Then, later, it's paged back in, but in a different physical location in memory. Your program still has the pointer value 800, but your program still works correctly because the operating system keeps track of where in physical memory 800, for your process, maps to.

People in the Windows world often say "virtual memory" when they mean "swap space" because Windows would call the amount of swap space "virtual memory size." But virtual memory is the technique described above. Read the Wikipedia entry from above, or read an operating systems textbook for a full discussion of it.

That's not entirely correct. The MMU generally handles virtual to physical memory address translation and the OS is only ever involved if there is a page fault. Outside of OS architecture and very specific and intended application, virtual/physical memory is completely transparent. When I hear "virtual memory" I assume reference to swap space unless otherwise noted because the technical meaning has such a specific domain.

That's why I noted that the CPU caches the mappings in the TLB. On modern processors, the MMU is integrated with the rest of the processor, so I didn't see the need to introduce another TLA. It's a part of the processor just as much as, say, the floating point unit is. The whole point of my discussion with small pointer values was to demonstrate that the virtual to physical mapping is transparent.

When I hear "virtual memory," I think of the computer science meaning. However, I am a researcher in high performance computing systems.

Awesome explanation.

Still, an SSD makes this all better. When I was using virtual memory on a Ubuntu server and put the swap partition on an SSD, everything worked great. On a rotating platter, not so much.

Oh, no question, SSDs are an improvement. I'm just clarifying the systems concepts involved. SSDs everywhere may change some assumptions in the operating system. For quite a while now, we've considered paging to "disk" as performance death, and have gone through contortions to make good decisions about which pages should be paged out. If paging to "disk" everywhere gets several orders of magnitudes cheaper, we may want to do less up-front processing trying to determine good victim pages.

It's where your "virtual memory lives" in the event that you run out of physical memory. They are not interchangeable.

It is entirely possible to have a virtual memory design with less virtual address space than physical address space (eg: 32-bit virtual, 34-bit physical), and virtual addressing would still be useful in this context.

Assuming you have demand paging, your virtual memory doesn't "live" anywhere.

Reply on news.ycombinator.com