[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sawmill's dataspaces and the Hurd's physmem
From: |
yuan Darwin-r62832 |
Subject: |
RE: Sawmill's dataspaces and the Hurd's physmem |
Date: |
Tue, 18 Oct 2005 19:42:27 +0800 |
Hi Neal,
I think these 2 approachs are not incompatible. Here are the reasons,
1. In Hurd's approach, every application could manage its own physical
memory. However, for most of application developers, they don't want to take
care of the VM replacement policy. To solve this problem, Hurd has to provide a
general VM server to be the pager of this kind of applications. However, as the
philosophy of Hurd, should this applications trust this server?
2. In Sawmill's DS approach, every task(AS) has a specific thread named
"region mapper" to be the pager of other threads. It captures the page fault,
then decide to forward it to corresponding server, and get mapped. So from the
higher level point of view, these servers are the pagers of the task. If Hurd
application should trust that general VM pager, the applications using
Sawmill's DS framework should trust these servers as well.
3. Relative to Sawmill's approach, Hurd provides a clear & great
physical memory server, which makes the whole physical memory of platform could
be fairly used by all of the servers & applications.
Therefore, we can use Hurd's physmem server as the central controller.
Sawmill's DSMs apply physical memory from it. The applications who wanna use
Sawmill's approach could still walk on their own way. For some applications who
wanna manage their own physical memory, they can apply memory from physmem
server directly.
[ physmem ]
/ \
|_ _|
[ DSM ] [Hurd app] (manage physmem by itself]
/ \
|_ _|
[Sawmill app] [Sawmill app]
Best Regards,
Darwin
- RE: Sawmill's dataspaces and the Hurd's physmem,
yuan Darwin-r62832 <=