Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:6587 comp.os.386bsd.bugs:1738 comp.os.386bsd.misc:1402 Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!emory!ogicse!psgrain!agora!davidg From: davidg@agora.rain.com (David Greenman) Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs,comp.os.386bsd.misc Subject: Re: [FreeBSD-1.0R] Epsilon -> Release patches - problems Message-ID: <CG5LAE.4o3@agora.rain.com> Date: 8 Nov 93 03:20:35 GMT Article-I.D.: agora.CG5LAE.4o3 Organization: Open Communications Forum Lines: 26 >You are (again) incorrect. It simply means that assuming the worst >possible memory fragmentation you can still allocate a 4k buffers. >That's fine if you only care about 4k file systems. Given 8k file >systems, it is still not that difficult to get enough fragmentation to >cause noticable performance degradation--the most likely case being if >you also try to use 4k file systems at the same time (say, on a floppy >disk). Because of the limit on number of buffers, even if all of the headers point to 4k buffers, and even if all of the 4k buffers occupy every other page in the malloc area, as soon as you want to expand a buffer to be 8k, the FS cache releases one of the 4k buffers, and you then have an 8k hole. Like I said, even with worst-case fragmentation, there is no problem. >The worst case would obviously be alternating allocations of 4k and 8k >blocks; it is easy to see why this would cause many unfillable 4k >fragments in the address space. Assuming less adversarial timing, the >fragmentation will build up over the life of the system, but it will Again, the limit on the total number of buffers makes this problem null. FreeBSD's malloc code no longer holds on to freed page-sized allocations as the code in 386BSD did. This make all the difference. -DG