Skip site navigation (1)Skip section navigation (2)
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>