Date: Wed, 16 May 2001 10:14:15 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Charles Randall <crandall@matchlogic.com> Cc: Roger Larsson <roger.larsson@norran.net>, Rik van Riel <riel@conectiva.com.br>, arch@FreeBSD.ORG, linux-mm@kvack.org, sfkaplan@cs.amherst.edu Subject: Re: RE: on load control / process swapping Message-ID: <200105161714.f4GHEFs72217@earth.backplane.com> References: <5FE9B713CCCDD311A03400508B8B30130828EDA8@bdr-xcln.corp.matchlogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105161714.f4GHEFs72217>