Date: Thu, 19 Jun 2003 22:07:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Schultz <das@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c Message-ID: <3EF2969F.4EE7D6D4@mindspring.com> References: <20030618112226.GA42606@fling-wing.demos.su> <20030619113457.GA80739@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote: > As a side note, I also think it's important that the new > implementation have a clean separation between user data and FS > metadata, so that they are not in direct competition with each > other for memory. This was the rationale behind the original VM and buffer cache separation. Instead of coming from a limited system resource shared between the two, they came from a limited system resource shared between the two, and scavanged pages from each other and caused thrashing. This was especially obvious in programs that mmap'ed a lot of file data into memory (e.g. "ld"), and then by seeking around, thrashed all the code pages out of core. The net result of this approach is an HI disconnect when doing large compiles uin an X term, when all of X's pages are thrashed out, and you move the mose and the cursor does... nothing... for... a... very... long... time... -- not a good situation. > The present buffer cache may be too limited for > the massive number of dependencies softupdates needs to track for > FS-intensive loads, but we also don't want lots of accumulated dirty > buffers from heavy FS activity to force application data out of memory. This basically says that you need to stall dependency memory allocation at a high watermark, and force the update clock to tick until the problem is eliminated. The acceleration of the update clock that takes place today is insufficient for this: you need to force the tick, wait for the completion, and force the next tick, etc., until you get back to your low water mark. If you just accelerate the clock, the hysteresis will keep you in a constant state of thrashing. > The original buffer cache design is untenable largely because > Dyson wanted to maintain compatibility with existing FS > interfaces. At the time, the problem was that the vmobject_t's were not reference counted, and allowed to be aliased. This was more or less a debugging decision, which was made because there were a couple of places where the system created unintentional aliases for VM objects, and had some pretty severe crashes as a result. Once these were tracked down, intentional aliases would have been an acceptable approach. But instead, what happpened was that the buffer cache entry became married to the vnode structure, on a 1:1 basis, forever more. When the pager changed to assume this, then everyones fate was irevvocably sealed. 8-(. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EF2969F.4EE7D6D4>