This would require everything to be static linked?!?!?! What if the
solution isn't to kill the offending process, but to add more
swapspace? Then you would also have to include:
dd # to allocate the swapfile on disk
mkswap # to create the swapspace
sync # ... always a good idea
swapon # ... go!
What if "the right thing" is a 3rd, yet to mentioned solution? You'd
have to account for that too. (The above 4 lines could be incorporated
in a shell script which could check, say every 5 seconds, if the free
amount of memory dropped below a certain minimum. If the free amount of
memory dropped below the line, a new swap-file was initialized. But I
think this is a kludgy solution - one which I'll propably do anyway.
Maybe with some help from the kernel - could be nice if one had a
'kmemd', much like kmod, which could dynamically allocate some swap on
the disk .... anybody?)
The solution I offer is a general one. No matter what "the right
thing" is when having close to nothing in free memory, 'root' have the
chance to login and see if he can either kill some processes (if that's
the right thing) or add some more swap-space (if that's the right thing)
or some 3rd solution.
The way it's done, you can fine-tune the 'memory-reserve' with a page
granularity.
But I still want's to know if my implementation is clean with respect to
what I want to obtain .... ;o)
>
> Assuming that it's run from CRON and cron is already in memory at the
> time (which it usually will be as it auto-runs once a minute), my
> analysis would go as follows:
>
> 1. First, let's assume the script takes up a page of memory, either
> 4k or 8k depending on the system.
>
> 2. According to my info, /bin/ash is just over 61k in size, so would
> occupy 64k for itself, and let's say another 16k maximum for its
> data and stack combined. That's 80k total.
>
> 3. Also according to my info, /usr/bin/killall is 8540 bytes in size,
> so would occupy either 12k or 16k depending on page size, and lets
> allow a further 16k for data and stack combined. At worst, that's
> 32k total.
>
> Adding those together, I get 120k required at worst.
Not counting the size of the various libraries used, if the utilities
are dynamically linked ...
>
> Comments, anybody ???
>
> Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/