Date: Mon, 23 Sep 1996 22:00:34 +0200 From: Poul-Henning Kamp <phk@critter.tfs.com> To: current@freebsd.org Subject: Re: cvs commit: src/lib/libc/stdlib malloc.3 malloc.c Message-ID: <4455.843508834@critter.tfs.com> In-Reply-To: Your message of "Mon, 23 Sep 1996 12:26:45 PDT." <199609231926.MAA02944@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>phk 96/09/23 12:26:43 > > Modified: lib/libc/stdlib malloc.3 malloc.c > Log: > phkmalloc/3 > Various neat features added. More documentation in the manpage. > check the manpage. A couple of words about this version of phkmalloc. I would actually like to make the 'A' option default, so that all problems are reason for a core-dump. Although some programs handle a malloc error, a lot doesn't. I think it makes a lot more sense to core-dump a process that gets an malloc error these days, than let it do it itself later on. If you can, please enable it and tell me if anything unexpected breaks. Second, if you have a program that you think will be interesting for me to include in my simulation suite, do this: ktrace -t u -i <your program> gzip -9 ktrace.out and upload the ktrace.out.gz file to freefall under a good name and email me the location. The file will contain a trace of all calls made to malloc/realloc/free so I can use it to run through my simulations here. There is nothing in the file about what you used the memory for, only the size and the addresses. (use kdump to verify that claim) I can provide you some feedback on the memory use patterns of the process if you want me to. The cache have been reduced a great deal, after some careful studies. Nobody really had any benefit from the huge cache, so it's cut from 100 to 16 pages now and you can tweak it with the '<' and '>' options. On any machine which is paging out, using the 'H' option should avoid the situation where a page containing nothing that anybody care about is paged out, instead the page will be reclaimed, and if phkmalloc needs it again, it will get a freshly washed page instead of a page-in of the stale page. I'm very interested in comments about the impact of this option, if it's generally beneficial I'll make it the default. Please report comparable wall-clock durations for your benchmarks. (it has to be wall-clock because we have to measure the impact in time waiting for disk). I have cleaned up and documented the various messages that phkmalloc may splatter on your stderr in the manpage. Any mandoc wizards may want to kill me for they way I've done it, but I will gladly accept patches for it. I have also added a "char * malloc_options;" so that you can set specific options in a program, in case you happen to know what you want. For instance any daemon should probably set at least 'H'. Finally I have added a check for recursively entering this mess. This can happen if you're in there already and a signal is posted for you. Well, sorry, that is not supported, and now it will refuse to do so. If this is a big problem anywhere (it shouldn't be) I could add another option that will block signals while in here, but that will have a serious impact on performance. I also fixed the thread locking, which was screwed up because of the internal recursive calls to the public functions. Now all internal calls go to the internal functions. You will have to do a tiny bit of surgery to make this compile other places, as the utrace() isn't available in older FreeBSD's or other OS's. Some of the processes I have studied could use a rewrite in their memory handling, which is in some cases rather archaic, but I refuse to tune phkmalloc to degenerate cases, even though they're called cpp and ld. If you feel like tweaking that kind of stuff I have some tools you might want. I intend to put them in src/tools later when they have been polished a bit, but if you can't wait for that, send me email. As far as I can see, there is little that can be tweaked in general any more, the next step is a kernel maintained "green/yellow/red" memory loading stated delivered by signal to the processes, and quite frankly, I doubt it would ever pay back for its complexity. So, just like I said last time: This is it :-) Thanks to John Dyson for making madvise do what was needed for option 'H'. Input most welcome! Poul-Henning -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4455.843508834>