On Wed, 2006-09-13 at 10:43 -0500, Aleksandar Milivojevic wrote:
> Quoting Steve Bergman <steve@xxxxxxxx>:
>
> > When it comes to swap, I'm a big believer that swap is a good thing.
>
> Yes, swap is a good thing. As long as it is used only to swap out
> never or almost-never used data. On the other hand, if an app needs 1
> gig of memory, and it really crunches on that data, relaying on swap
> to give it 1 gig of space is a bad idea. It'll kill machine.
>
Yes. But all should keep in mind that swap was originally not for
performance, but to allow (*e.g.*) PCs running UNIX system III or V (and
other *IXs as they appeared) to support multiple users (usually
dedicated to one or two apps) when hardware was very expensive. A
"reasonably configured" node might have a 286/386/486/586 CPU, 100MB
disk or two and 640K of ram (later 1MB). Depending on time frame, maybe
4 or 5 thousand dollars? Add a couple serial I/O cards and some printers
and terminals (Wyse 50/55/60, e.g.) and you had "state of the art"
capability. This was about the time that 4GL was coming into vogue and
relational data bases with SQL interfaces were just starting to supplant
proprietary stuff. "Canned" business applications were beginning to make
their appearance.
As the cost structure and technological capabilities changed, the
utility of "swap" (in terms of dollars) decreased but the people using
it did not see it that way. If one wants to promote *IX (any flavor)
across the widest possible potential user base, then one must continue
to support swap for those whose $s matter more than latency. But the
tuning ability is needed for those to whom latency is more important.
The problem in the current discussions, IMO, is that the tunability of
the original *IX (rife with high and low water marks for cache, swap
activity, text, data, I/O of various types, ...) could satisfy the needs
of admins willing to learn it, but was considered too "complex" by the
community at large (that is, those who paid for it all - business)
because they had a hard time finding the expertise and paying the price
demanded by that expertise. Plus, it needed real data (performance
statistics) to be useful. This meant no instant decisions *or* a high
risk that several iterations would be needed to get it right. This meant
even more cost. If the platform was changed, the cycle repeated.
That complexity has been replaced by (apparent) simplicity and so now
people gripe because it is not skewed to their personal needs and they
have insufficient tools to bias their system in the direction needed.
So you have those saying "...interactivity should never be
sacrificed..." and those saying "... but look what you gained that you
didn't notice". Both are right in their environments.
Whenever you have highly technical skilled people working in
environments defined by the bean-counters, you'll hit situations like
this. Iteratively.
For that reason, I tend to both ignore and discount all such
discussions. Cost structure is such now that those who desire minimal
latency should have it with zero-swap (if they are satisfied with the
risk) and those more concerned with hardware costs and reduced risk
should have the swap they want.
But in no case can we ever go back to the complexity that used to
provide the almost infinite tunability that allowed all needs to be
satisfied (reasonably so) because the folks controlling the money would
not tolerate it. The needed expertise would be both missing and too
costly in the view of business (they'll go offshore until the salaries
rise sufficiently there too).
A better solution is potentially laying in the proper application of
"pre-configurations" that exist already: "workstation", "server", ...
The problem is that they are not "tuned" in the sufficiently in the
direction needed for the implied use of the particular "pre-
configuration". And if they were more aggressively tuned, some customers
would be dissatisfied because it was too aggressive while others thought
it not aggressive enough.
And other would just plain apply the wrong tool to the job (use a
"server" setup for workstation, ...).
IMHO
--
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
