MICRO-KERNELS
New Generation Innovation
The contents






Traditional OS view & its problems.
Micro-kernel : introduction to concept.
First generation micro-kernels.
Obvious advantages.
Some Implementation problems.
Second generation micro-kernels.



L4 Kernel.
Exo-Kernel.
SPIN OS.
The contents (contd…)
Traditional OS view

Prerequisite component : TCB
 Kernel is OS part of TCB.
 Kernel is monolithic.
(includes sched, fs, n/w, mm, dd etc..)
 Kernel abstracts & protects system resources.
(PMVM, DISKFILES, CPUprocesses)
Advantages of this kernel

Portable interface to underlying machine.
 Large, generic, default functionality base.
(Applications need not worry about device
drivers or memory management policies )
 Provides protection.
(kernel controls use of all resources.)
Serious disadvantages






Huge kernel size.
ONLY privileged ones can access and manage
system resources. (kernel itself, or servers.)
Applications are “forced” to use implementation
of these privileged ones.
This generic implementation is bound to be
imperfect for specific application needs.
Why ?
Because of typical performance/cost tradeoffs.
What to do ?
1st generation micro-kernels.

Remove un-wanted components.

Implement all services as external servers.
(fs, mm, dd, n/w etc …)

All servers run in user mode.
What are the benefits ?

Smaller kernel. (hand-held devices ?)
 OS is more modular, flexible, extensible
and customizable.
 More than one implementation possible of
various services. (can co-exist).
 May even run concurrently, if needed.
 Easy crash recovery (only servers crash)
Minimal** implementation
primitives required.

Assumptions



Support for un-trustworthy applications
Page based virtual memory implementation by h/w.
Issues for such a system :




Protection scheme.
Guarantee of Independence.
Interrupt handling.
IPC
Implementation
Two concepts solves all above problems –
the concept of Address spaces & threads.
 Traditional address space : mapping
associating virtual page  physical page.
 New : Initially, only 1 global address space,
representing the physical memory.
 New address spaces can be recursively
constructed outside the kernel.

Address space construction

For this support, 3 operations provided in
the micro-kernel.
 GRANT, MAP, FLUSH.
 Using these kernel provided primitives,
memory management and paging schemes
can be implemented outside kernel.
Definitions of Primitives

GRANT



Owner can grant “its” pages to anyone else,
provided receiver agrees to take it.
Granted page removed from granter’s addr space.
MAP


Owner can map “its” pages to anyone else’s address
space, provided receiver agrees for it.
Page can now be accessed in both addr spaces.
Definitions contd…

FLUSH





Owner can flush any of “its” pages.
Flushed pages remain accessible to owner.
But once flushed, the page is removed from any
other address space (non-owner), where it may
possibly have been mapped.
Note that owner do NOT need explicit permission
from other “mappers” before flushing.
Idea is that anyway page belongs to self only, and
users of this page “had already accepted this” .
Where are these reqd.?

MAP & FLUSH used for implementing
memory managers and pagers on top of
micro-kernel.
 GRANT only used in special circumstances


When page mappings should be passed through a
controlling sub-system without burdening the
controller’s address space.
(See figure below for explanations.)
Explaining primitives
User A
User N
grant
Pager - F
map
Pager
Pager – f2 (fs)
f1 (fs)
map
disk
Standard pager
Threads concept

Micro-kernel support the notion of threads
at the lowest level of abstraction, within the
kernel.
 A thread t is an activity executing inside an
address-space as.
 t is characterized by registers, stack-ptr,
state information :: (which as it belongs to)
How this satisfies everything ?

Protection & Independence are obvious due to
very structure of separate AS concept.
 IPC can be realized by transferring messages
between kernel “threads”. Note that this forms the
basis of communication and is used for
implementing operations like map and grant.
 Interrupts are treated as IPC messages. Hardware
is regarded as set of threads.
Questions / thoughts ?

How can this model help provide
“controlled” access? think of ACLs. !!



Provide “access rights” concept on pages.
Map/Grant can “copy”/”move” source’s rights.
Flushing can “revoke” permissions.
What can be built on top ?

Memory manager (stacked ?)
 Pager – can implement virtual mem., resident
memory for device drivers etc.
 Device drivers.


They will directly access hardware I/O ports which are mapped
into “its” address space. Messages are recvd from h/w
(interrupts) through IPC.
Secondary cache / TLB handlers.
 R-IPC (RPC)
 UNIX server ( system calls.)
1st generation problems

Performance was terrible.
 IPC costs (200 #sec vs. 40 #sec)
(All user level servers would be accessed by
RPC mechanism.)
 High MCPI costs (memory cycle per inst)
Even upto .25 CPI (additional). !!
 Non-Portability.
 WHY ?
MCPI problems due to …

Increased cache misses due to ;
– Worse locality properties of the combined
micro-kernel OS code.
– System self-interference, incorrectly
invalidating cache lines, due to more
modularity of the OS.
– More inter-module copying due to the higher
modularity of the OS.
Why Non-Portability ?

Problems with Portable kernels :– Can not take advantage of specific hardware
– Can not take precautions to circumvent or avoid
perfromance problems of specific hardware
– Additional layer ( abstraction of hardware)
costs performance.

WE SHOULD ACCEPT THAT microkernel is going to be h/w dependent.
Example : 486 Vs Pentium
486
Pentium
TLB entries, 32
ways
32i + 64d
Cache size
Line, thru
Fast instr.
Segmt reg.
8Ki + 8Kd
32B, back
0.5-1 cycle
3 cycles.
8K
16B, through
1 cycle
9 cycles
Differences :

Pentium micro-kernel will use segment
registers for implementing user address
space
 486 will have to use conventional hardwareaddress-space switch because of expensive
segment register operations.
 This is Due to points 2 &3 in table above.
Conclusions

Micro-kernel design offers great flexibility
and innovation in way world percieves OS.
 Micro-kernels must be developed perprocessor, but performance achieved is
probably worth the effort.
 More work needed in this area.
 STEP TOWARDS 2nd generation microkernels.