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. -- Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060605/8da23209/attachment-0002.sig>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jun 05, 2006 at 05:00:52PM -0400, 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.Well Bill, I'm sure they will be happy to receive a patch from you, with a new VM implementation that actually works (including for SMP machines, and multiple platforms). No ? Well, talk is cheap, isn't it ? - -- Rodrigo Barbosa <rodrigob at suespammers.org> "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEhJ6fpdyWzQ5b5ckRAnxDAJ4puKz7CSq1woGrveJT7H8GrOeHHACbBbko JUI12oYs4e+eKqxDyL6gWTY=k9Jh -----END PGP SIGNATURE-----
On Mon, 2006-06-05 at 17:00 -0400, 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.Actually, having these computed dynamically is much better than having to manually tune them every time your mix of programs change or you add memory except in some very unusual circumstances like a server that does a single job forever. In the general case consider whether you'd rather hire an expert admin to keep your system tuned or buy an extra gig of ram and let the OS figure out how to use it. -- Les Mikesell lesmikesell at gmail.com
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. -- Sam W.Drinkard -- sam at wa4phy.net http://wa4phy.net Augusta Area Mesonet cell 706.825.8513 Home 706.868.7253 MAIL 4428 Branchwood Drive, Martinez Georgia, 30907-1304