Re: [HACKERS] Safe/Fast I/O ...

> Date: Mon, 13 Apr 1998 12:26:59 -0400 (EDT)
> From: Garrett Wollman <wollman(at)khavrinen(dot)lcs(dot)mit(dot)edu>
> Subject: Re: [HACKERS] Safe/Fast I/O ...
>
> [Please forgive me for the way this post is put together; I'm not
> actually on your mailing-list, but was just perusing the archives.]
> if your operating system is at all reasonable, using
> memory mapping allows you to take advantage of all the work that has
> gone into tuning your VM system. If you map a large file, and then
> access in some way that shows reasonable locality, the VM system will
> probably be able to do a better job of page replacement on a
> system-wide basis than you could do with a cache built into your
> application.

not necessarily. in this case, the application (the database) has
several very different page access patterns, some of which (e.g.,
non-boustrophedonic nested-loops join, index leaf accesses) *do not*
exhibit reasonable locality and therefore benefit from the ability to
turn on hate-hints or MRU paging on a selective basis. database query
processing is one of the classic examples why "one size does not fit
all" when it comes to page replacement -- no amount of "tuning" of an
LRU/clock algorithm will help if the access pattern is wrong.

stonebraker's 20-year-old CACM flame on operating system services for
databases has motivated a lot of work, e.g., microkernel external
pagers and the more recent work at stanford and princeton on
application-specific paging, but many older VM systems still don't
have a working madvise().. meaning that a *portable* database still
has to implement its own buffer cache if it wants to exploit its
application-specific paging behavior.
--
Paul M. Aoki | University of California at Berkeley
aoki(at)CS(dot)Berkeley(dot)EDU | Dept. of EECS, Computer Science Division #1776
| Berkeley, CA 94720-1776