>> Can we see if we can arrive at a figure for the amount of RAM
>> needed for a script similar to the following to run, which is
>> basically what Brian's looking at.
>> Q> #!/bin/ash
>> Q> /usr/bin/killall -9 $1
> This would require everything to be static linked?!?!?!
Ooopppsss...I didnae think of that...lemme see...
Q> [me@here] ls -lGL `ldd \`which ash killall\`` 2> /dev/null | uniq
Q> -rwxr-xr-x 1 root 159488 Jul 14 06:04 /lib/ld-linux.so.2*
Q> -rwxr-xr-x 1 root 3063916 Jul 14 05:59 /lib/libc.so.6*
OK, we're now in the 3.25 Meg region...so we would need at least that
much as the minimum to use.
Incidentally, would it not be better to specify the actual memory size
rather than the number of pages, for consistency across versions...
> 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!
Would all of those be run in parallel, or would it just be one at a
time? If the latter, all we'd need is room for the one that used the
most RAM...
> 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?)
In each case, the restricting factor is the amount of memory occupied
by the largest single process, since in the limiting case, each step
in a pipeline can be replaced by running each command between a couple
of files on disk and manually chaining them together, so...
Q> ps ax | sort | less
...could become...
Q> ps ax > /tmp/part.1
Q> sort < /tmp/part.1 > /tmp/part.2
Q> less < /tmp/part.2
Sure, it's less convenient, but if it works, why fix it...
> 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.
I'm not disputing that, just curious as to how little memory root
could get away with...
> The way it's done, you can fine-tune the 'memory-reserve' with a
> page granularity.
Would it not be better to specify the reserve in K and have the
kernel convert that to/from page counts?
> But I still want's to know if my implementation is clean with
> respect to what I want to obtain .... ;o)
Unfortunately, I'm not in a position to comment on that, being too new
to the game to make suchlike judgments...
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/