Hi Robert,
the 5 mappings are on average (and configurable!). They are not assigned to
one particular frame. I used the term frame in the context of available
physical memory. you need some additional mapping entries for devices (like
video frame buffer). The kernel must keep track of the mappings, because
otherwise the pager can not revoke a page from an address space, where the
page was indirectly mapped to. (e.g. A=pager mapps to B and maps to C, D,
and E. Hereby, A is only aware of the mapping to B.) But the kernel concept
allows to map any available/mapped memory from one address space to
another.
Volkmar
Robert Kaiser <rob(a)sysgo.de> on 02/22/99 11:43:16 AM
Please respond to Robert Kaiser <rob(a)sysgo.de>
To: Volkmar Uhlig/Watson/IBM
cc:
Subject: RE: L4 Mapping question
Hi Volkmar
Thanks again for your response!
On Mon, 22 Feb 1999 vuhlig(a)us.ibm.com wrote:
> there is one mapping entry per associated page per address space. that
> means, if you map a page to 2 address spaces you need 2 mappings. The
> current L4 version allocates the mappings statically (currently 5 entries
> per frame, but this is configurable at startup time).
I seem to have a little difficulty with the term "frame". It may have
to do with the fact that I don't have much of an Intel background (I'm
developing mostly for MIPS machines). Does it mean something like
"physical page" ?
If so, that would mean that there is a hard (though configurable) limit
of five address spaces that can share any given page. Is that correct ?
> The idea is, that the kernel can revoke pages from sigma 0, what is not
> implemented yet. I don't see the case, where you want to map a lot of
pages
> into all address spaces.
The case I had in mind is shared memory between user tasks running
on top of a -say- L4Linux server (and possibly being unaware that
they are in a microkernel environment).
I would not like the microkernel to impose a limit on the number of
tasks that can share a given piece of memory.
> Furthermore is your calculation not right. You can
> map a page to multiple address spaces multiple times (at different
virtual
> addresses) - so there is no limit of needed mapping-entries per page.
Oops, I hadn't thought of that!
Would it be such a bad idea to move the bookkeeping for fpage_unmap
out of the microkernel altogether? I mean, the pager has to do some
bookkeeping anyway (like Sigma0 marks all pages once it maps them
so it can refuse multiple mapping attempts). So, if the fpage_unmap
syscall would just unmap a given fpage for a *single*, given address
space and the pager would be responsible for making one fpage_unmap
call for each task it has previously mapped the fpage to, then all
bookkeeping would be in one place (i.e. the pager). This would
simplify the microkernel, reduce it's memory footprint and leave
the implementation details up to the user-space pager, which seems
to me like the "microkernel way" of doing things.
Of course, this would result in more system calls being made (thus
more overhead), but I guess that in the usual cases (such as up to
five tasks sharing a page) this should be negligible.
I suppose there must be some other good reason why it wasn't done
this way...
Thanks again
Rob
----------------------------------------------------------------
Robert Kaiser email: rkaiser(a)sysgo.de
SYSGO RTS GmbH
Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80
D-55129 Mainz / Germany fax: (49) 6131 9138-10