Re: "caching pager"

[Ognyan Kulev]

Roland McGrath wrote:
> This is the effect you get from operating your own pager that you are
> mapping from yourself in Mach.  You can layer the interface you are talking
> about on top of libpager.  When the VM system decides to eject a page, you
> the pager find out and you can also have data structures mapping memory
> object pages to the mappings you've made, and unmap them.

Ah, yes, it would be something like convenience layer for filesystems. 
It is not very hard to be implemented and can be as mini-library for 
ext2fs, like pokel.

There are two problems to use this idea now: pager with 64-bit offsets 
and notification when page is evicted by the microkernel.  I'll have to 
take a look if one struct pager can be used for multiple mappings, most 
probably it can.

Unfortunately, vm_map uses 32-bit offsets for defining the region that 
is to be mapped.  This is a big stopper for 64-bit pagers.  I can think 
of 2 solutions: vm_map64 (and all the consequences in other kernel 
calls), and pager_map that have to be used instead of vm_map, and that 
creates memory objects by demand.  The second solution creates one more 
problem: when using libpager of another user process, memory object port 
is not enough anymore to map parts of this out-of-process pager.  It 
smells like pager.defs.

Talking about libpager, I've never heard anything, positive or negative, 
about Neal's proposed API change[1][2].

[1] http://mail.gnu.org/archive/html/bug-hurd/2002-04/msg00110.html
[2] http://mail.gnu.org/archive/html/bug-hurd/2002-04/msg00203.html

Regards
--
Ognyan Kulev <ogi@{fmi.uni-sofia.bg,fsa-bg.org}>
7D9F 66E6 68B7 A62B 0FCF  EB04 80BF 3A8C A252 9782