Messages in this thread | | | Date | Sat, 07 Nov 1998 00:28:36 +0100 | From | Brian Schau <> | Subject | Re: [PATCH] Patch to Memory Subsystem ... (Needed?) |
| |
Riley Williams wrote: > > Hi Brian. > > >> 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...
:o)
> > 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... >
Yes, propably. But as stated earlier this was a quick hack. I think I added something like 4 or 5 lines in total. Somebody might want to add the desired functionality. I might ...
> > 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...
Ok, I see. Libc *should* (meaning really should!) be in memory - are there any userspace programs which doesn't need libc? So, your earlier calculations seems right - if you add the size of libraries needed other than libc.
> > > 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...
So am I. That's why I want other to evaluate it .... ;o)
> > 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/
| |