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@sysgo.de on 02/22/99 11:43:16 AM

Please respond to Robert Kaiser rob@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@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@sysgo.de SYSGO RTS GmbH Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80 D-55129 Mainz / Germany fax: (49) 6131 9138-10