Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:6585 comp.os.386bsd.bugs:1736 comp.os.386bsd.misc:1401
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!darwin.sura.net!haven.umd.edu!news.umbc.edu!eff!news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mycroft
From: mycroft@duality.gnu.ai.mit.edu (Charles Hannum)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs,comp.os.386bsd.misc
Subject: Re: [FreeBSD-1.0R] Epsilon -> Release patches - problems
Date: 08 Nov 1993 01:48:06 GMT
Organization: MIT Artificial Intelligence Lab
Lines: 31
Message-ID: <MYCROFT.93Nov7204806@duality.gnu.ai.mit.edu>
References: <CG57or.LHL@agora.rain.com>
NNTP-Posting-Host: duality.ai.mit.edu
In-reply-to: davidg@agora.rain.com's message of 7 Nov 93 22:26:49 GMT
In article <CG57or.LHL@agora.rain.com> davidg@agora.rain.com (David
Greenman) writes:
The above paragraph is assuming that you allocate more buffer
headers than pages; if not, then it hardly matters, because you
could just assign a page to each buffer header statically.
Yeah, well, we don't! ...and this makes all of the rest of your
analysis false.
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).
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
still, in *fact*, occur.
And you have not justified the position that the buffer cache is
`dynamic'. In this context the word means (and always has) that it
responds to other needs for memory in the system--primarily user
processes.