Hi: I recently formatted the HDD and told cfdisk to reserve 128MB for the swap. I did not do it well, because I now see it has 257040 sectors allocated, and 257040 * 512 / 1024**2 = 125.5MB. The problem was that cfdisk expresses quantities in 1000**2 units and not 1024**2. Rather, the problem is I did not know it.

But I have 128MB of memory installed in my machine. Can the system performance be degraded by this? Kernel is 2.6.21.5, distro is Slackware 12.0. Thanks.

P.S.: The distribution author says "your amount of memory or 128MB, whichever is greater. Also, the minimum RAM required, according to him is 48MB.

The difference between 125MB of swap and 128MB of swap is unlikely to matter.

Depending on how you use the system, maybe 125MB is enough or maybe 128MB would still have been significantly too little.

OK. I've found the way to expand the swap. So I'll give it 256MB, sticking to the principle of twice the RAM. Thanks.

The principle of twice as RAM is simply nonsense. There is only one factor that dictates the amount of swap you should have: the workload. Or said otherwise: If your system really needs an amount of swap that is twice as large as your memory you should consider that the workload on that machine is not appropriate, the machine is under-dimensioned.

0 members found this post helpful.

The latter is very probable, or the OS is overdimensioned, although I must say I did not take that principle very seriously. All I know is that virtual memory has been invented so as to have more memory than the amount of RAM present in the machine. This memory is external, of course. This would make the principle plausible. I only speak for what I have learned reading the iAPX286 Programmer's Manual.

The surest principle, anyways, seems to be that of the workload, as you stated. But without experimentation, how to determine this workload a priori, when I have to allocate the swap space?

I guess the question is a matter of preference:

Would you rather a) suffer bad performance as the physical RAM has
been gobbled up, and the OS swaps inactive processes out and back
in in a time-slice manner, or b) would you rather the kernel shot a
random process that consumes lots of memory dead (google OOM killer)?

While (if the swap actually gets utilised to a large extent) any
swapping will degrade performance, it gets (for obvious reasons)
worse the more of SWAP you have compared to RAM. A 1-to-1 ratio
will already be quite poor (unless it's on SSD), a 2-to-1 will keep
chugging along, but you won't have much fun using it interactively ...



Cheers,
Tink

I think your post deserves careful examination. For that, I would need to have clarified the first paragraph:

a) The physical RAM has been gobbled up: that is, the RAM has been exhausted, no more RAM is available. Ah, but I have the SWAP.

b) The OOM condition. No more RAM, no more SWAP. I.e, no virtual memory at all.

Well, I would certainly choose neither case. b) is inadmissible. The a) situation can no longer run any program, for programs run in RAM. So, I see I do not quite get the meaning of the paragraph.

I would like to understand it, as it would help me understand the rest of the post.

swap *IS* ram.
Just horrendously slow ram.
And if ram is full, and you run yet another program the kernel will shuffle
the whole memory allotted to some running program which currently doesn't
have a time-slice to actually execute out to disk. That's the whole idea
of having swap memory. But because of the inefficiency of disk in terms
of speed everything goes very slowly.

I can only guess at what is confusing you, since I don't see anything here that is confusing.

My guess is that you don't know Linux moves pages from ram to swap. Grossly over simplifying: When ram is needed for a new or running program, the OS will remove the least recently used pages from memory to make that ram available. So in your (a) situation, ram was "exhausted" but that doesn't stop a new program from running. The new program isn't given swap space. The new program is given ram and older pages are displaced. If those older pages are anonymous displacing them uses swap space.

That typically makes the system slower because whatever process last used those older pages may soon use them again, causing a delay while Linux brings those pages back and displaces other pages.

That is not the way the term "ram" is normally used.

That is nonsense. There have been OS's that worked that way. But Linux never did.

That really depends on how the system is used. Having a large amount of swap space occupied does not make the system slower. Frequently reading pages from swap space makes the system slower. So after an anonymous page is written to swap space, what matters is how soon does that process need that page again.

Consider a typical server example. Some service uses some anonymous memory during startup that it will never touch during normal operation. Maybe it will use that memory again during shutdown. The server has plenty of ram, but eventually the fact that everything in cache is much newer than the last access to that anonymous memory causes it to swap out. Now some swap space is occupied until the distant future when the server is next shut down (our Linux servers often stay up for years). Swap space is occupied but that directly causes zero performance loss while it indirectly causes a trivial performance gain (more memory available for the cache).

Consider a less typical, but plausible, home example: A home user locks a session (rather than logging out) and walks away. Another member of the family sharing that computer logs in a new session without disturbing the locked session. The computer has plenty of memory for one user to run a browser and word processor and maybe a few other programs all at the same time. But the locked session was using near the computer's ram capacity. Without swap, the new session would run very slowly for lack of ram. The use of swap directly causes each stalled program of the locked session to recover more slowly when the first user is back and gives input to that program. But the use of swap also causes the second user to have a full speed system instead of a badly memory limited system. That second effect is a bigger speedup than the first effect is a slowdown.

johnsfine, your exposition couldn't be clearer.

Well, of course Linux moves pages from ram to swap. I dare almost say, the CPU does, because it offers a great deal of support for the mechanism of virtual memory.

My confusion arises from this:The question is of the form "What do you prefer: A or B". This or an exclusive disjunction (XOR, if you prefer). I have only two alternatives: either A or B. No other choice.

But then the question is very similar to "Do you prefer to be hit by a car or to have a finger cut?" I would answer, neither one nor the other. It is supposed the alternative is large swap space or small swap space. This is what this thread was about. And at this distance from the begining of the thread, I have come to believe that it depends on the type of usage the system will be subjected to and, of course, on the amount of installed RAM.

Correct, within the context of discussion, as understood by at least some participants.

Yes. The understood context was a Linux system with an unusually low amount of ram combined with the expectation that the workload of the system would not fit in that amount of ram.

If you knew that the workload would also be unusually low in ram needs, then that choice between bad and worse doesn't apply.

If the decision on the size of physical ram isn't immutable, then there are more than two choices: Buy more ram is one of the choices.

It's oversimplified. But at the end of the day swapping is doing
something quite similar to it.



Cheers,
Tink