Date: Fri, 12 Oct 2001 10:01:07 -0500 (CDT) From: mark tinguely <tinguely@web.cs.ndsu.nodak.edu> To: dillon@earth.backplane.com, Patrick.Cipiere@UDcast.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigfree, free what? Message-ID: <200110121501.f9CF17Y14052@web.cs.ndsu.nodak.edu>
next in thread | raw e-mail | index | archive | help
Patrick Cipiere <Patrick.Cipiere@UDcast.com> says: > > :We are currently working with FreeBSD 4.3 and we found out that > :kldloading/kldunloading modules working with contigmalloc()/contigfree() > :like if_xl.ko produces a memory leak. > : > :This is due to the contigfree() function which seems to uncompletely release > :the memory ressource allocated in vm_page_array. > : > :When contigmalloc() steps in vm_page_array, it does not find back > :the pages previously released by contigfree() > :The loop vm/vm_page.c is this one: In FreeBSD 4.4 (and I do not think there is any change from 4.3), I placed the contigmalloc/free using the if_xl.c structures in a new PCI probe routine so it gets called several times in a boot process. I also placed some checks on vm_map_delete to see if the range of map gets modified (and therefore some pages are not freed. Everything works correctly; the correct amount is free, and the entry that this map is found in is completely the amount of the contigmalloc. Most of the time, I get the very same range, but as I started adding drivers and reserving memory, the start of contigmalloc creaps up, as expected. I think you are hitting the problem that contigmalloc cannot be guarrenteed to work once the physical memory becomes used and there is no range large enough for your new contigmalloc. That is why large contigmallocs are done at boot time. I did not try this with a loadable module, so I can't say if there is or is not a feature of the loading/unloading of the module that allocates memory that fills part of your contiguous range. Do you wish patches to VM code to verify that the free is done completely? --mark tinguely To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110121501.f9CF17Y14052>