From owner-freebsd-arch Wed May 16 10:41:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by hub.freebsd.org (Postfix) with ESMTP id 939C437B422 for ; Wed, 16 May 2001 10:41:42 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 7BB1C16B50 for ; Wed, 16 May 2001 14:41:35 -0300 (EST) Received: (qmail 25576 invoked by uid 0); 16 May 2001 17:40:13 -0000 Received: from duckman.distro.conectiva (HELO duckman.conectiva.com.br) (root@10.0.17.2) by burns.conectiva with SMTP; 16 May 2001 17:40:13 -0000 Received: from localhost (riel@localhost) by duckman.conectiva.com.br (8.11.3/8.11.3) with ESMTP id f4GHfZq16610; Wed, 16 May 2001 14:41:35 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Wed, 16 May 2001 14:41:35 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Matt Dillon Cc: Charles Randall , Roger Larsson , , , Subject: Re: RE: on load control / process swapping In-Reply-To: <200105161714.f4GHEFs72217@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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