Subject: Re: Unified Buffer Cache 1st snapshot
To: Chuck Silvers <chuq@chuq.com>
From: Stefan Grefen <grefen@hprc.tandem.com>
List: tech-kern
Date: 09/21/1998 11:25:33
In message <4917.906350832@chuq.com> Chuck Silvers wrote:
> hi folks,
>
[...]
> the interfaces for the kernel to access the page cache are ubc_alloc()
> and ubc_release() (ala segmap_getmap() and segmap_release()).
> you get a mapping onto the part of the file the user wants to change,
> do a uiomove() to copy the user's buffer in, and then release the mapping.
> mappings are cached in an LRU fashion.
Why copy and not map, mapping eliminates a copy and conserves memory ???
> async i/o, readahead, clustering, partial-page stuff, or dynamic
> buffer-cache resizing. I have ideas, but haven't had time to
> do anything about these yet. most of this should be fairly
> straightforward (except maybe partial pages).
If we want to do async IO onto files the 'correct' way, we should
wire the region
set it COW (for the process only, it was a write else it stays
as it is)
create a list of phyiscal pageID's
initiate the IO ...
at the end of the IO, unwire the page, if it was copied free it
if not mapped elsewhere
This scheme can be used for general async IO. (AIX has such a feature,
as_att and friends).
I need that feature in the forseable future, and would implement it
if there is consensus hoe to do it.
It did it on top of a SVR-V4 vm and its pain if can't change the source.
Stefan
--
Stefan Grefen Tandem Computers Europe Inc.
grefen@hprc.tandem.com High Performance Research Center
--- Hacking's just another word for nothing left to kludge. ---