Re: [U]VM subsystem for L4 X.2 (and later)

[Espen Skoglund]

[Farid Hajji]
> So at the moment, I'm preferring UVM over the other alternatives,
> though I didn't made up my mind yet.

> The UVM system consists of 2 parts:
>   a. The MI UVM code
>   b. The MD pmap module

> a. manages the bookkeeping of the VM data structures in a machine
> independent way. It decides which pages should be made available,
> which should be COWd etc...

> b. programs the MMU in a machine dependend way (remember: NetBSD runs
> on a _lot_ of different architectures!). The UVM <-> pmap interface
> is the same across all supported architectures, so all we need to do
> is to write yet another pmap module for L4.  This pmap/l4 module
> would use L4 IPCs to implement its services just like
> pmap/{i386,m68k,...}  uses CPU instructions/registers.

> So, the issue of an L4 pmap seems resolvable, both for current L4
> (say: hazelnut) and for the upcoming Version 4 spec. It is just a
> matter of using L4's memory mapping primitives inside a new pmap.c
> to implement the functions required in pmap(9).

Question: how does UVM deal with multiple page sizes?  Can it deal
with multiple page sizes at all?  Being able to do so can prove very
beneficial since the TLB working sets are effectively reduced and such
reductions can probably have a high impact on system performance (in
particual in multiserver systems where one has to take into account
the working sets of all system components).

I can't really tell how much reductions in the TLB working set really
helps (maybe the UNSW people can shed some light on that), but one
should at least try not to use a design which rules out such
optimizations.

        eSk