Be Careful What You Wish For

As the saying goes, "Be careful what you wish for, you just might get it".  I was visiting one of my favorite SSD sites, storagesearch.com, which led me to Solid Access, the text under the Technology tab.  In their spiel was this:

I/O acceleration is achieved in applications by off-loading I/O-demanding files ("hot files", typically less than 5% of the content) onto an SSD for processing at RAM speed and using mechanical disks (or RAIDs) to process the remaining "cold files". This instantly improves the efficiency of the application servers by recovering CPU cycles formerly lost in I/O wait loops.


Why did this get my attention, you may ask?  I will answer.  Well, duh!  Of course!  Multiprogramming, even on multicore/processor hardware, depends on "idle" cycles, and such idle cycles predominantly derive from I/O waits.  Mainframers learned this in the 1960's.  If there is a proliferation of SSDs, whether my version where SSD is the sole storage medium, or the case where SSD is merely cache, one will see a reduction of I/O waits.  Multiprogramming becomes much more problematic, expensive, and delicate, in this circumstance. 

With I/O waits, scheduling is easy (well, as easy as that sort of thing gets); the application that *can't* do anything is skipped in favor of one which can use the cpu.  What happens when all applications the OS sees are ready and rarin' to go?  Algorithms will need to be developed which rank applications' priorities, somehow or another.  Do the order entry folks get priority, or the accountants updating the GL?  Who's the top dog? 

*nix operating systems have nice, but nice, ultimately, depends on human intervention.  I'd wager that nice is unknown to most coders whose work ends up on *nix systems.  It's going to be interesting.

I just let my fingers do the searching, and found this article, which does mention SSD and scheduling together, although I don't see any direct discussion of removing I/O waits and multiprogramming.  So, there is some consideration out in the literature; this paper is March, 2010.

We aren't in Kansas anymore.  SSD proliferation may mean that multiprogramming is passe'; each core/processor will be dedicated to an application/process, since there isn't exploitable I/O wait in the machine anymore.  If storage is on PCIe, or similar, I/O wait gets yet slimmer.  Oh my!  OS's would be greatly simplified, since multiprogramming support is the gnarliest part of any industrial strength OS. 

What about database engines?  They act like an OS, in that they have much the same responsibility:  serving multiple clients, although the clients' needs are constrained.  In the old days, there were Pick and AS/400; "integrated" OS and database.  Could we see linux/db in the next few years?  Might be.  It's been accepted wisdom in the *nix world for many years that one should reduce, or even eliminate, OS buffering in favor of the database doing all of that itself; after all, what point is there to having multiple memory images of a file that's only of interest to the engine?   Hmm.