2009-10-08

Outline
• Why current operating systems are not
suitable for manycore operation
Multicore operating systems and • Two approaches for alternatives
resource management – Barrelfish: a multikernel
– fos: the factored OS
Mats Brorsson • Multi/manycore resource management
KTH School of Information and – Resources to be managed
Communication Technology – Why an issue?
– Some results and ideas for the future

Literature for today Future manycore systems

• Wentzlaff, D. and Agarwal, A. 2009. Factored operating systems (fos): the case for a
scalable operating system for multicores. SIGOPS Oper. Syst. Rev. 43, 2 (Apr. 2009), • Cores will be many: 100s-1000s
76-85.
• Baumann, A., Barham, P., Dagand, P.E., Harris, T., Isaacs, R., Peter, S., Roscoe, T.,
Schüpbach, A. and Singhania, A. The Multikernel: A new OS architecture for
• Cores will be heterogeneous
scalable multicore systems, in SOSP’09: Proceedings of the 22nd ACM symposium
on Operating systems principles – In performance and capability
• Strömblad P., High Performance Packet Processing Enabled with a Hybrid SMP/AMP
OS Technology, ENEA White paper – In ISA (maybe)
• Zhang, X, Dwarkadas, S., and Shen K., Hardware Execution Throttling for Multi-core
Resource Management (USENIX 2009 short paper) – In accelerators
• Kyle J. Nesbit, Miquel Moreto, Francisco J. Cazorla, Alex Ramirez, Mateo Valero,
and James E. Smith, Multicore Resource Management, IEEE Micro special issue on
Interaction of Computer Architecture and Operating Systems in the Manycore Era,
• We may not have shared memory
May-June 2008.
– Coherence may not scale efficiently
• Available on Bilda
• Systems will be diverse

1
 2009-10-08

Why current OS:s are not suitable Fine-grained locking

• They assume shared memory • Linux is using fine-
grained locking for
• They require same ISA for all cores memory management
• They use fine-grained locking • Yet, after 4 cores, lock
contention begins
• Applications and OS interfere with each other
• Recent modifications of
• They need careful tuning to match each the dispatcher code in
architecture for highest performance Windows 7 to remove a
lock touched 6000 lines
of code in 58 files!

Applications and OS interfere The Multikernel (Barrelfish)

Design principles:
• Make all inter-core
communication explicit
• Make OS structure
hardware neutral
• View state as replicated
instead of shared

• Applications do not share a cache equally • Parallel applications may

• The OS has different cache locality properties still use shared memory if
hardware supports it
• The OS and applications interfere with each other

2

Motivations
• Systems are increasingly diverse
• Cores are increasingly diverse
• The interconnect matters
• Messages cost less than shared memory
• Cache coherence is not a panacea
• Messages are getting easier
Comparable performance
2009-10-08
Barrelfish
• An implementation of a multikernel
• Goals:
– Comparable performance on current multicore architectures
– Evidence of scalability
– Re-targeting to different hardware easy
– Can exploit batching and pipelining of messages
– Can exploit the modularity to place OS functionality according to the
HW topology or load
Evidence of scalability
3
 2009-10-08

Factored OS (fos) Messaging in fos

1. Application calls read, which calls the
message proxy lib
2. The message proxy lib constructs a
message to the file system service
3. The message proxy lib calls the fos-
microkernel to send the message
4. The fos-microkernel looks up the fs
server in the name cache
5. The fos-microkernel transports the
message to the dest
6. The receiving microkernel deposits
message in the fs request mailbox
• Space multiplexing replaces time multiplexing 7. The fs server processes the request
– Scheduling becomes a layout problem 8. The fs server returns the data to the
message proxy library who sends it as
• The OS is factored into function specific services 9.
steps 2-5 above
The proxy library unpacks it and
delivers the result to the application

The main run-loop of a server Resource management

• Additional resources: temperature and power

• Problem: how to manage resource usage to
match coexisting application needs with system
balance?

4
 2009-10-08

Execution throttling Virtual Private Machine Abstraction

• Slow down threads that want to use an
”unfair” amount of cache memory

Market Algorithms for Resource

Market Algorithm Idea
Management
• Execution is divided into time slices
• Each application is assigned (off-line, through
measurements or from heuristics) an initial resource
allocation (its virtual currency)
• At the end of a time slice, each application can use its
unused resources as currency to ”buy” additional
resources it had too little of
• The OS has to match applications with compatible
resource
• Applications are throttled when they risk consuming
their allotted resources before the end of the time slice

5
 2009-10-08

Next lectures
• Oct 9, 13-15 (tomorrow!)
– Håkan Zeffer about Transactional memory, the Rock from
Sun and the PISC architecture of Xelerated AB
• Oct 14, 13-17
– Seminar 2
– Beer/soda and snacks afterwards together with MSc thesis
proposals information
• Oct 16, 13-15
– Anders Wass and Andras Vajda from Ericsson AB about
multicore baseband processing
– Patrik Strömblad from Enea AB about OSE RTOS Multicore
edition