Ulf Carlsson wrote:
> > > ulfc@dione:~$ ./test
> > > failed to allocate 512 bytes (6307840 bytes already allocated)
> > > spinning ...
> > that's pretty normal for a 2.1 kernel, when running without swap.
> > I've tried it on a 64MB P5 system and test was able to get about 7MB
> > memory. With swap enabled I had to stop test to avoid running out of
> > swap space (which wasn't desired at that time:-)).
> Anyhow, it isn't normal to have every program complaining about OOM at
> 14 out of 32 megabytes allocated, no matter if you have swap enabled
> or not.
Yes and no. Personally I find the concept of running a modern system
without available swap somewhat perilous. I don't think there's much
reason for kernel developers to make sure they keep in mind that the
lunatic fringe is going to try it when they write the mmu code.
True, you shouldn't be getting error messages when you have 18 megs
free. Logic doesn't dictate that at all. But on the other hand, think
about your reasoning for running without swap.
The argument I usually hear is "I have 128 megs of ram and I don't want
anything hitting the swapper". I'm an OS/2 user (yes, we still exist,
much that IBM treats us like vermin) and I hear this from a lot of
novice OS/2 users. Under OS/2, it's an extremely bad idea to run without
swap space available because of the archetecture of the dynamic loader.
The folks who designed the memory manager in os/2 were mainframe geeks,
who used the logic that harddrive is cheaper than memory, and that it's
faster to load library functions from swap than it is to execute them
from the filesystem.
Therefore, one of the big reasons for OS/2 loading so slowly is that on
bootup, it loads as many DLL's as it can. It just keeps going and going,
wether you need them or not. And for the first hour or two of usage,
OS/2 is fairly sluggish as it swaps DLL's to disk to free up memory for
applications. This has the effect of annoying the average Windows user
who expects a big chunk of memory available immediately after bootup,
and expects to reboot within 6 hours of usage. But OS/2 was designed to
run unattended for weeks or months at a time (80+ % of the ATM machines
in north america are running OS/2 on modified PS/2 hardware) and after a
few hours of normal usage, OS/2 is a lean, mean, dynamic-loading
machine. You keep the functions you actually use in active memory, and
the ones you don't use so often are waiting in the swapper.
To give you some raw numbers, for about a year I was running with 48
megs of ram. On bootup, I would have 512k of ram free. After 3 hours
use, if I then closed all my applications, I would have 28 megs free.
And about 34 megs in use in the swapper.
But it gets yet more interesting. The archetects of OS/2 foresaw that
there would be libraries almost nobody uses. So there is an entire class
of library that loads directly into swap, never touching active memory
unless you try to use them. These days, most people end up needing them
once or twice a day. If you're running without swap, no matter how many
megs of ram you have, when it comes time to use one of those functions,
OS/2 will lock up. Unfortunate but true.
OS/2 is an extreme example of an agressive memory managment scheme.
Linux isn't anywhere near that involved. But the fact remains, you are
going to be loading code into memory that you are not going to use.
Where do you want that code to reside? Do you want it taking up $1/meg
RAM or do you want it taking up the slightly slower but far more
affordable disk space? You can set up a swap partition that's atleast
128 megs - how much does that 128 megs cost you?
Clearly, any memory managment scheme is going to be based on checks and
balances and have to be designed to make sure that things get used
efficently. Running without swap isn't efficent, and it's not logical to
design a managment structure that doesn't include it, so any memory
managment scheme is going to end up eventually making some assumptions
about it's presence.
The moral of the story is: You shouldn't be running without swap.
Complaining that something doesn't work when you do something you
shouldn't, isn't likely to illicit a response other than "stop doing
that thing you shouldn't be doing"