[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "caching pager"

From: Ognyan Kulev
Subject: Re: "caching pager"
Date: Fri, 15 Aug 2003 13:35:44 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]