Date: Tue, 17 Dec 1996 14:48:58 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dyson@freebsd.org Cc: terry@lambert.org, scrappy@hub.org, hackers@freebsd.org Subject: Re: Almost have mmap() figured, I think... Message-ID: <199612172148.OAA08978@phaeton.artisoft.com> In-Reply-To: <199612172119.QAA05589@dyson.iquest.net> from "John Dyson" at Dec 17, 96 04:19:17 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The Stevens book is the bible... but that example you might want to > > consider most relevent is in the cp code in /src/bin/cp/utils.c. > > > > John: there is still "#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED" in that > > code... is that right now? > > The ifdef can go away now -- no problem. The problem is a performance > issue where copying a large file will cause lots of memory usage... The > buffer cache is better tuned for file I/O. Any chance of per vnode working set restrictions? They would be easy to implement by keeping a page count and changing lru insertion order over the count, it seems to me. The SVR4 ld thrashed the cache by mmap'ing a bunch of files; the UnixWare folks seems to head off into the weeds at that point, including coming up with an entirely new scheduling class for their X server to fix the "move mouse, wiggle cursor" problem cause by it swapping the whole X server out while servicing the ld. A trivial working set restriction (no LRU on a per vnode basis) cleaned it right up without needing new scheduling classes and all that crap that they had added. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612172148.OAA08978>