[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Paging Interface
Re: Paging Interface
14 Jun 2002 23:26:26 +0200
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
address@hidden (Neal H. Walfield) writes:
> The Mach Paging Interface as Used by the Hurd
> --- ------------------------------------- - -
Thanks for an excellent introduction.
> The following describes how mappings are currently established under
> Mach by the Hurd. Some of the details have been abridged for the sake
> of brevity.
What if several processes wants to map the same thing? E.g. using mmap
on a device or an ordinary file. Who's responsibility is it that they
really end up sharing the same pages?
> One of my idea is to have a pager thread for each task.
Would this pager be a thread live inside the task which it serves? Or
in some separate more-or-less privileged task?
> What is not clear to me, however, is how we should manage physical
> memory. Would it be appropriate to have make every server a vm
I don't think I understand you here. I think the simplest way to get
started would be to have a server that talks to sigma0 and grabs all
the physical memory, and which implements an interface that let's
other servers allocate *and* deallocate pages. Optionally, one may
also add some protocol by which it could ask its clients to return
I'm curious about how such a server relates to the uvm memory system
Farid has talked about, but I guess uvm is a higher level thing?
> Perhaps, we should have multiply core servers which compete for
> physical memory at startup and then give it out according to some as
> of yet undetermined algorithm?
If you have several "core servers", they could cooperate by allocating
the pages they need from the above memory server.
But I'm not sure that's really useful. If what's needed is simply a
default pager (it's role is not entirely clear to me, though), then it
may make more sense to have a single default-pager server and let that
grab all sigma0's memory at startup.
Exactly what is the role of the default pager? My guess is as follows:
If no swap space is registered, it will only hand out real physical
pages, similarly to the above memory server. Clients can register as
swap space handlers, and when that happens, the default pager can hand
out more pages, and coordinate with the swap space handlers when pages
need to be swapped in or out.
Finally, there ought to be some hooks where the posix servers can get
into the memory allocation process, in order to implement limits.
- Paging Interface, Neal H. Walfield, 2002/06/14
- Re: Paging Interface,
Niels Möller <=