Date: Wed, 16 May 2001 14:41:35 -0300 (BRST) From: Rik van Riel <riel@conectiva.com.br> To: Matt Dillon <dillon@earth.backplane.com> Cc: Charles Randall <crandall@matchlogic.com>, Roger Larsson <roger.larsson@norran.net>, <arch@FreeBSD.ORG>, <linux-mm@kvack.org>, <sfkaplan@cs.amherst.edu> Subject: Re: RE: on load control / process swapping Message-ID: <Pine.LNX.4.33.0105161439140.18102-100000@duckman.distro.conectiva> In-Reply-To: <200105161714.f4GHEFs72217@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 May 2001, Matt Dillon wrote: > In regards to the particular case of scanning a huge multi-gigabyte > file, FreeBSD has a sequential detection heuristic which does a > pretty good job preventing cache blow-aways by depressing the priority > of the data as it is read or written. FreeBSD will still try to cache > a good chunk, but it won't sacrifice all available memory. If you > access the data via the VM system, through mmap, you get even more > control through the madvise() syscall. There's one thing "wrong" with the drop-behind idea though; it penalises data even when it's still in core and we're reading it for the second or third time. Maybe it would be better to only do drop-behind when we're actually allocating new memory for the vnode in question and let re-use of already present memory go "unpunished" ? Hmmm, now that I think about this more, it _could_ introduce some different fairness issues. Darn ;) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0105161439140.18102-100000>