From owner-freebsd-arch Wed May 16 10:14:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 2004937B424 for ; Wed, 16 May 2001 10:14:23 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4GHEFs72217; Wed, 16 May 2001 10:14:15 -0700 (PDT) (envelope-from dillon) Date: Wed, 16 May 2001 10:14:15 -0700 (PDT) From: Matt Dillon Message-Id: <200105161714.f4GHEFs72217@earth.backplane.com> To: Charles Randall Cc: Roger Larsson , Rik van Riel , arch@FreeBSD.ORG, linux-mm@kvack.org, sfkaplan@cs.amherst.edu Subject: Re: RE: on load control / process swapping References: <5FE9B713CCCDD311A03400508B8B30130828EDA8@bdr-xcln.corp.matchlogic.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :We found that without this, Solaris was aggressively trying to cache the :huge input file at the expense of database load performance (but we knew :that we'd never access it again). For some applications this is a huge win :(random I/O on a file much larger than memory seems to be another case). : :Would there be an advantage to having a similar feature in FreeBSD (if not :already present)? : :-Charles We've talked about implementing O_DIRECT. I think it's a good idea. 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message