On Wed, 2006-09-13 at 10:43 -0500, Aleksandar Milivojevic wrote: > Quoting Steve Bergman <steve at rueb.com>: > > > 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