lkml.org 
[lkml]   [1998]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.055 / U:1.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site