logo
Published on KernelTrap (http://kerneltrap.org)

GNU/Hurd: L4 Port Gets Inital Memory Management Framework Including Self-Paging Tasks

By mbanck
Created Jan 19 2005 - 11:02

As a major step towards the Hurd on the L4 microkernel, Neal Walfield [interview [1]] has committed [2] physmem [3] (the physical memory manager) and libhurd-mm [4] (the per-task physical and virtual memory manager) to the L4/Hurd repository [5]. This means that tasks are self-paging now and mmap/munmap work, paving the way for further development.

Contrary to most other operating systems including the current Hurd on Mach implementation, the scheduling and virtualization of physical memory (i.e. the multiplexing of physical memory) of the Hurd on L4 takes place in user space on a per task basis ([1 [6]], [2 [7]], [3 [8]]). Applications virtualize physical memory themselves (which is typically done by using a library), allowing them to optimize around the actual availability rather than forcing the kernel to attempt to guess access patterns. This is unlike the UNIX-like paradigm where applications receive virtual memory and they do not know and cannot easily influence the scheduling attributes of the contents. This allows for applications whose memory usage patterns do not match LRU to use their own memory management routines, for example databases, multimedia applications, garbage collectors and data analysis programs.

With regards to future development, Neal says: "From here, the next step is to implement copying physical memory between containers. With this mechanism available, work can seriously start on the device driver framework (deva and fabrica). This is also a prerequisite to the porting of libpager, the Hurd's library for application level pagers, which is needed to flesh out the implementation of the root filesystem [...] and portability issues with the filesystem, file and io RPC interfaces". Discussions about this are already taking place [9] on the l4-hurd mailing list [10].


From: Neal H. Walfield
Subject: Physmem exists; Tasks self-paging
Date: Wed, 12 Jan 2005 11:17:31 +0000

Good Morning,

For those of you following commit-hurd@gnu.org [11], you will have noticed
[1] that last night I checked in a real physmem server and added
libhurd-mm.  For those of you who don't follow address@bogus.example.com [12],
last night, I checked in a real physmem server and added libhurd-mm.

physmem is the physical memory manager.  It doesn't do any virtual
memory management at all: it schedules physical memory allocations;
scheduling of the content (i.e. multiplexing of the frame) is the
exclusive domain of the applications.  In its current state, physmem
is able to allocated physical memory into and deallocate it out of
containers.  Clients (i.e. applications) can also map physical memory
into their address spaces.  The current code supports sharing of
physical memory between containers (a necessary prerequisite for COW
and copying physical memory between containers), however, actual
copying between containers has not yet been implemented.

libhurd-mm is the default per-task physical and virtual memory
manager: it multiplexes the physical memory available to the tasks,
manages the virtual address space mappings, handles page faults and
pages data in and out.  Currently, it supports allocating and
deallocating virtual memory mappings backed by anonymous storage.  The
task's pager thread is also brought up and it is able to handle page
faults.

In terms of POSIX, this means that mmap (for anonymous memory) and
munmap work which is a prerequisite for pretty much everything.

Details about the implementation can befound here [2,3].  For details
about the design, please look at Chapter 5 of the design document.


From here, the next step is to implement copying physical memory
between containers.  With this mechanism available, work can seriously
start on the device driver framework (deva and fabrica).  This is also
a prerequisite to the porting of libpager, the Hurd's library for
application level pagers, which is needed to flesh out the
implementation of the root filesystem (initially using a ramdisk until
the IDE driver is ready) and portability issues with the filesystem,
file and io RPC interfaces.

Thanks,
Neal


[1] http://lists.gnu.org/archive/html/commit-hurd/2005-01/msg00014.html [13]
[2] http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/hurd/hurd-l4/physmem/README?rev=1.2 [14]
[3] http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/hurd/hurd-l4/libhurd-mm/README?rev=1.1 [15]

Source URL:
http://kerneltrap.org/node/4580