William L. Maltby wrote:
I can't resist. Read the thread that was pointed to on lkml. ROTFLMAO.
*Real* UNIX addressed these problems long ago. I guess the "Gurus" suffer from NIH (Not Invented Here) syndrome.
Given a "general purpose" system, tunability is a must. UNIX, as delivered by USL in such examples as Sys V, had tunables that let admins tune to their needs. A single "swappiness" value is woefully inadequate.
Among the tunables were how much memory for cache, how much for buffers, how much for X/Y/Z, high and low water marks for all sorts of memory related stuff and a very valuable attribute bit for executables called the "sticky bit". It is not the "sticky bit" as used now. It said lock this app in memory and never swap it. A variation on that (couldn't keep original semantics with the size of apps these days) would address some of the "responsiveness" issues raised by some. Some admin tunables would address the other issues.
The "Gurus" need to learn something my father taught me. "A smart man learns from his mistakes. A wise man learns from the mistakes of others". I'm really smart. :-( And, apparently, so are the "Gurus". To think they have VM this long and no one has thought to swipe these good ideas from real UNIX. And they're still argueing about all that as if it has never been hashed out and addressed before.
When I started out in UNIX, it was Interactive 1.3, if I remember, and it was a dog. Coming from a DOS world, I guess I was overwhelmed by all the things that could be tuned in the kernel. I probably didn't learn much about them then, and still don't know a lot about it, but unless you actively try some of the suggestions and see how things work or behave, then I guess you still don't know. There seems to have been some built in tradeoffs over the course of the years in the unix-like OS's, but it's still seems to work the same. I wonder how well Interactive 3.4 would stack up to today's versions of CentOS, all the *BSD's and such.