Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!usenet.ins.cwru.edu!agate!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!in2.uu.net!news.thepoint.net!news1!not-for-mail From: root@dyson.iquest.net (John S. Dyson) Subject: Re: Linux vs. FreeBSD ... (FreeBSD extremely mem/swap hungry) X-Nntp-Posting-Host: dyson.iquest.net Message-ID: <4oabbl$6n1@dyson.iquest.net> Sender: news@iquest.net (News Admin) Organization: John S. Dyson's home machine References: <3188C1E2.45AE@onramp.net> <4o3ftc$4rc@zot.io.org> <31A5A8F6.15FB7483@zeus.co.uk> <31A5D0A8.59E2B600@zeus.co.uk> Date: Sun, 26 May 1996 19:27:49 GMT Lines: 52 In article <31A5D0A8.59E2B600@zeus.co.uk>, Damian Reeves <damian@zeus.co.uk> wrote: > >and more, indeed I'm sure I'm completely mad. Have you actually >watched the RSS of the Xfree 3.1.2 Server increase as you repeatedly >load and quit Netscape? > That is due to the way the X Server allocations clash with the malloc code (Even gnumalloc has that problem, but handles the situation a bit better.) We are working on a solution to the problem with some kernel and malloc mods. The default API into the kernel (on Linux or FreeBSD) is not very efficient handling the problem (even though it can be fixed as-is), so we are enhancing both the malloc and FreeBSD kernel. > >Have you ever wondered why the code to display a little mail box icon >and stat a file every few minutes (read xbiff), requires 1.3Mb of >memory?? > Looking at your PS output below shows that the process has not run very long (.34 secs). If there was no paging activity since starting xbiff, you are seeing the effects of the address space preloading. > >I'll even give you my ps listing for it: > > PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM >COMMAND > 1200 S 0:00.34 11 1122 10 224 1364 - 12 0.0 4.4 xbiff > > >Have you actually looked through libc code to tell me there are no >memory leaks? Have you constructed a proof in your favourite temporal >logic? > It is obvious, that since (.text+.data+.bss+malloc) is 224K, and we don't use mmap except for very limited data structures (today) in our malloc, that the only likely memory leak is limited to 224K in the process image, given your ps output. The RSS is large because mmaped regions are mostly shared with other processes. The VSZ does NOT include mmaped regions at all. The (.text, part of .data, and much of the mmaped space) are all shared. The above output does not necessarily indicate any leaks. Resident pages in shared regions are mapped immediately during the mmap system call. This happens even if the pages are never needed by the process. The feature to preload the page-tables has significant performance advantages with very little cost. (Costs about 26usecs to fault on my machine, and less than 1usec to preload each pte.) John dyson@freebsd.org