Date: Sun, 17 Dec 1995 12:13:10 -0800 From: Poul-Henning Kamp <phk@freefall.freebsd.org> To: hackers, kaleb@x.org Subject: Re: growing X server processes Message-ID: <16151.819231190@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
> > > I use it for everything. Without gnumalloc my server would easily > > > grow to ~10meg and never shrink. This was not very good on my 8meg ram/ > > > 32meg swap machine to have a third of my swap consumed by unused server > > > > > You should try out the malloc in -current then. I would probably do even > > better than gnumalloc in low-ram environments. > > > > Here's a patch that is a slight improvement over the malloc.c in -current. > If you run a ktrace on the simple test program that I posted previously > you'll see that it behaves a little better in that case. > > But it's still not perfect. With this patch my X server idles at ~3.5meg, > as opposed to ~4meg without it and ~3meg using gnumalloc. I think this > points out that your free page management needs to be rethought. > As the author of our current malloc I'd like to point out a couple of common fallacies in comparing mallocs. 1) You don't reall care about how many pages you have sbrk'ed. You care about how many are in RAM. The "Current Working Set" is the term often used. Both top and ps shows it. The "phkmalloc" tries to minimize the number of pages used, not the number of bytes. 2) All the pages which have been sbrk'ed but which are not used, they only occupy swap-space, and they are cheaper to get back than getting new pages from the kernel. Being too eager to sbrk(2) backwards is not always a good thing. Anyway, you hack is indeed a cute little optimization, which I should have thought about :-) Peter moved the page-directory into mmap'ed pages, and that was also a good idea, keep 'em coming.... :-) Have you found any timewise measurable performace difference ? Poul-Henning
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16151.819231190>