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