The code size of Fiasco µ-kernel

[Jonathan S. Shapiro]

On Mon, 2003-12-08 at 05:33, jwy002 wrote:
> Hi,
> 
>   Can anyone give me a rough figure about
>   how much memory space is needed by L4 u-kernel?
>   Thanks.
> 
> Joseph

Joseph:

I cannot provide an answer (I'm sure one of the L4 people will), but
depending on what you are trying to achieve, you may be asking the wrong
question.

Code Size:

Within reasonable limits, it doesn't matter what the size of the kernel
is. We have so much memory on modern machines that the difference in
code size between a 20k kernel and a 60k kernel simply doesn't matter
very much.

For code size, the right question is usually: what is the size of the
active working set? This is a slightly revised version of a question
Jochen used to talk about when he argued that "smaller is better".

There are rare events in the life of a kernel. Sometimes they need to be
handled inside the kernel to preserve protection. Statistically
speaking, this code is never run and as a result it doesn't really
affect performance very much. This is why EROS and L4 performance were
identical back when L4/x86 was 12 Kbytes of code and EROS was ~94 Kbytes
of code -- both had a working set size of about 7 Kbytes.

Others may disagree, but as a designer I wasn't really worried about the
extra 21 pages of code space -- it was only 0.5% of system memory at the
time (16 Mbytes were typical). Today, that kernel's code would only be
0.03% (256 Mbytes now typical). Actually, the EROS kernel today is
smaller than the old one, so it would be even less.



Data Size:

For data size, matters are much more tricky. I would suggest that the
following questions are usually good indicators. A rationale is provided
for each.

1. What is the resident set size of the kernel data?

Issue: Many of the kernel data structures scale linearly with physical
memory size.

Resident set size includes both non-pageable data (not much of this in
either EROS or L4) and some pageable data. Typically, there is a certain
amount of metadata that must remain in memory in order to make use of a
resource. For example, in paging structures you lose access to the page
if you have to throw away the mapping database entry.

Since these entries are needed to make use of the data, they are for
practical purposes non-evictable -- you can rotate them in and out as
pages come and go, but the total *number* of them that are required to
make efficient progress tends to remain the same.

A better way to ask the question may be: what is the resident set size
expressed as a function of physical memory size?

2. What is the size of the kernel virtual memory region, and how does it
relate to the resident set size?

This will tell you how much memory the kernel can scale to handle on
that implementation. For smaller installations (e.g. embedded) it may
not matter much.

Rationale: if the kernel is at or near the total available virtual
region, it is unlikely to scale well as the size of main memory goes up,
because many of the kernel data structures scale linearly with physical
memory size.

On the x86, this is becoming an issue for EROS, and we are in the
process of changing the kernel memory map to deal with it.


3. If essential operations are NOT performed within the kernel, what is
the total code and data size (in pages) required to deploy a credible
system.

  For L4, include: sigma-0, rmgr, some copy-on-write handler
  For EROS, include: space bank, constructor, metaconstructor, PCC, VCSK

Drivers tend to be roughly comparable in size across kernels, but if you
are comparing to Linux you will need to include those as well.


shap