Date: Mon, 6 Apr 1998 01:39:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dswartz@druber.com (Dan Swartzendruber) Cc: dyson@FreeBSD.ORG, dg@root.com, dag-erli@ifi.uio.no, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: swap-leak in 2.2.5 ? Message-ID: <199804060139.SAA10532@usr04.primenet.com> In-Reply-To: <3.0.5.32.19980405182046.009137d0@mail.kersur.net> from "Dan Swartzendruber" at Apr 5, 98 06:20:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> My only quibble with this technique is that it would seem to make it > >> harder to tell if your machine is really running low on swap or not > >> (e.g. swap as backing store for stack/heap/whatever *is* critical and > >> allocation failure can cause application failure, whereas swap being > >> used to cache random cruft is in the "who really cares" department). > >> Or is there some way to tell the difference? > >> > >It is difficult not only to tell if you are low on swap, but also it > >is hard to quantify being low on memory. I have been thinking about > >this over the last year or so. > > It was actually kind of embarrassing. I convinced a local ISP to start > converting their servers from Linux (what I recommended a few years ago > when I didn't know different :)) One of the admins (who has some Linux > experience) asked me why it was using swap. I gave the canonical reply. > He asked the question I just posed. I had no good reply :( I've been thinking about this as well. I think it should be relatively easy to (ab)use procfs and /dev/kmem to get at what pages are allocated to processes, which ones are clean, and so on. Procfs might need extended, but so what? This info is available from the SVR4 procfs; I used a simple "RLE" representation to find out that if you reference page zero on SVR4, instead of blowing up, it maps a zero-filled page in there. Bletch! I was considering writing a graphical tool to display this; maybe this will be my first real excuse to forray into AWT and JNI. Hopefully someone will beat me to this; I'm not terribly motivated to get that deep into AWT without some guarantee of a commercially usable JVM on FreeBSD. Kaffe is partly there, but you are still screwed by the non-public Sun "classes.zip". The base design I had in mind was a 128x128 (yes, limited to 64M) display of 4k page allocations, with the ability to "magnify" the grid to the point where you can see PID's (or 'shared'). Colors whould show mapping status (read-only, write-only, execute-only [if the bit were maintained; Intel is stupid], copy-on-write, text, data, kernel, and shared library, and clean [cached, unused]). Probably alternate mappings would be hand for "topographic" coloring based on number of mappings, number of aliases, etc.. Be quite a cool toy if I ever get around to writing it. ;-). I'm currently downloading the Mozilla source... I expect it to keep me busy for a while. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804060139.SAA10532>