Advanced Operating Systems - PowerPoint PPT Presentation

Loading...

PPT – Advanced Operating Systems PowerPoint presentation | free to download - id: 5d3879-ZWZkM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Advanced Operating Systems

Description:

Advanced Operating Systems Lecture 3: OS design University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani Advanced Operating Systems – PowerPoint PPT presentation

Number of Views:227
Avg rating:3.0/5.0
Slides: 103
Provided by: LarryPe9
Learn more at: http://ece.ut.ac.ir
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Advanced Operating Systems


1
Advanced Operating Systems
Lecture 3 OS design
  • University of Tehran
  • Dept. of EE and Computer Engineering
  • By
  • Dr. Nasser Yazdani

2
How to design an OS
  • Some general guides and experiences.
  • References
  • Exokernel An Operating System Architecture for
    Application Level Resource Management, Dawson
    R., Engler M, Frans Kaashoek, et al.
  • On Micro-Kernel Constructions,

3
Outline
  • New applications/requirements
  • Organizing operating systems
  • Some microkernel examples
  • Object-oriented organizations
  • Spring
  • Organization for multiprocessors

4
New vision
  • Two important problems location and scale.
  • Ubiquitous computing tiny kernels of
    functionality
  • Virtual Reality
  • Mobility
  • Intelligent devices
  • distributed computing" make networks appear like
    disks, memory, or other nonnetworked devices.

5
What is the big deal?
  • Performance
  • Border crossings are expensive
  • Change in locality
  • Copying between user and kernel buffers
  • Application requirements differ in terms of
    resource management

6
Operating System Organization
  • What is the best way to design an operating
    system?
  • Put another way, what are the important software
    characteristics of an OS?
  • What should be in OS kernel or application or
    partitioning.
  • Is there a minimal set for kernel?

7
Important OS Software Characteristics
  • Correctness and simplicity
  • Power and completeness
  • Performance
  • Extensibility and portability
  • Flexibility
  • Scalability
  • Suitability for distributed and parallel systems
  • Compatibility with existing systems
  • Security and fault tolerance

8
Common OS Organizations
  • Monolithic
  • Virtual machine
  • Structured design
  • Layered designs
  • Object-Oriented
  • Microkernels
  • Trade off between generality and specialization

9
Monolithic OS Design
  • Build OS as single combined module
  • Hopefully using data abstraction.
  • OS lives in its own, single address space
  • Examples
  • DOS
  • early Unix systems
  • most VFS file systems

10
Pros/Cons of Monolithic OS Organization
  • Highly adaptable (at first . . .)
  • Little planning required
  • Potentially good performance
  • Hard to extend and change
  • Eventually becomes extremely complex
  • Eventually performance becomes poor
  • Highly prone to bugs

11
Virtual Machine Organizations
  • A base operating system provides services in a
    very generic way
  • One or more other operating systems live on top
    of the base system
  • Using the services it provides
  • To offer different views of system to users
  • Examples - IBMs VM/370, the Java interpreter

12
Pros/Cons of Virtual Machine Organizations
  • Allows multiple OS personalities on a single
    machine
  • Good OS development environment
  • Can provide good portability of applications
  • Significant performance problems
  • Especially if more than 2 layers
  • Lacking in flexibility

13
Old idea
  • VM 370
  • Virtualization for binary support for legacy apps
  • Why resurgence today?
  • Companies want a share of everybodys pie
  • IBM zSeries mainframes support virtualization
    for server consolidation
  • Enables billing and performance isolation while
    hosting several customers
  • Microsoft has announced virtualization plans to
    allow easy upgrades and hosting Linux!

14
Layered OS Design
  • Design tiny innermost layer of software
  • Next layer out provides more functionality
  • Using services provided by inner layer
  • Continue adding layers until all functionality
    required has been provided
  • Examples
  • Multics
  • Fluke
  • layered file systems and comm. protocols

15
Pros/Cons of Layered Organization
  • More structured and extensible
  • Easy model and development
  • Performance Layer crossing can be expensive
  • In some cases, unnecessary layers, duplicated
    functionality.

16
Two layer OS Designs
  • Only two OS layers
  • Kernel OS services
  • Non-kernel OS services
  • Move certain functionality outside kernel
  • file systems, libraries
  • Unlike virtual machines, kernel doesnt stand
    alone
  • Examples - Most modern Unix systems

17
Pros/Cons of two layer OS
  • Many advantages of layering, without disadvantage
    of too many layers
  • Easier to demonstrate correctness
  • Not as general as layering
  • Offers no organizing principle for other parts of
    OS, user services
  • Kernels tend to grow to monoliths

18
Object-Oriented OS Design
  • Design internals of OS as set of privileged
    objects, using OO methods
  • Sometimes extended into application space
  • Tends to lead to client/server style of computing
  • Examples
  • Mach (internally)
  • Spring (totally)

19
Object-Oriented Organizations
  • Object-oriented organization is increasingly
    popular
  • Well suited to OS development, in some ways
  • OSes manage important data structures
  • OSes are modularizable
  • Strong interfaces are good in OSes

20
Object-Orientation and Extensibility
  • One of the main advantages of object-oriented
    programming is extensibility
  • Operating systems increasingly need extensibility
  • So, again, object-oriented techniques are a good
    match for operating system design

21
How object-oriented should an OS be?
  • Many OSes have been built with object-oriented
    techniques
  • E.g., Mach and Windows NT
  • But most of them leave object orientation at the
    microkernel boundary
  • No attempt to force object orientation on
    out-of-kernel modules

22
Pros/Cons of Object Oriented OS Organization
  • Offers organizational model for entire system
  • Easily divides system into pieces
  • Good hooks for security
  • Can be a limiting model
  • Must watch for performance problems
  • Not widely used yet

23
Microkernel OS Design
  • Like kernels, only less number of abstractions
    exported (threads, address space, communication
    channel)
  • Try to include only small set of required
    services in the microkernel
  • Moves even more out of innermost OS part
  • Like parts of VM, IPC, paging, etc.
  • System services (e.g. VM manager) implemented as
    servers on top
  • High comm overhead between services implemented
    at user level and microkernel limits
    extensibility in practice
  • Examples - Mach, Amoeba, Plan 9, Windows NT,
    Chorus, Spring, etc.

24
Pros/Cons of Microkernel Organization
  • Those of kernels, plus
  • Minimizes code for most important OS services
  • Offers model for entire system
  • Microkernels tend to grow into kernels
  • Requires very careful initial design choices
  • Serious danger of bad performance

25
Organizing the Total System
  • In microkernel organizations, much of the OS is
    outside the microkernel
  • But that doesnt answer the question of how the
    system as a whole gets organized
  • How do you fit together the components to build
    an integrated system? While maintaining all the
    advantages of the microkernel

26
Some Important Microkernel Designs
  • Micro-ness is in the eye of the beholder
  • Spin
  • X-kernel
  • Exokernel
  • Mach
  • Spring
  • Amoeba
  • Plan 9
  • Windows NT

27
Mach
  • Mach didnt start life as a microkernel
  • Became one in Mach 3.0
  • Object-oriented internally
  • Doesnt force OO at higher levels
  • Microkernel focus is on communications facilities
  • Much concern with parallel/distributed systems

28
Mach Model
User processes
User space
Software emulation layer
4.3BSD emul.
SysV emul.
HP/UX emul.
other emul.
Kernel space
Microkernel
29
Whats In the Mach Microkernel?
  • Tasks Threads
  • Ports and Port Sets
  • Messages
  • Memory Objects
  • Device Support
  • Multiprocessor/Distributed Support

30
Mach Task Model
Address space
Process
User space
Thread
Process port
Bootstrap port
Exception port
Registered ports
Kernel
31
Mach Ports
  • Basic Mach object reference mechanism
  • Kernel-protected communication channel
  • Tasks communicate by sending messages to ports
  • Threads in receiving tasks pull messages off a
    queue
  • Ports are location independent
  • Port queues protected by kernel bounded

32
Port Rights
  • mechanism by which tasks control who may talk to
    their ports
  • Kernel prevents messages being set to a port
    unless the sender has its port rights
  • Port rights also control which single task
    receives on a port

33
Port Sets
  • A group of ports sharing a common message queue
  • A thread can receive messages from a port set
  • Thus servicing multiple ports
  • Messages are tagged with the actual port
  • A port can be a member of at most one port set

34
Mach Messages
  • Typed collection of data objects
  • Unlimited size
  • Sent to particular port
  • May contain actual data or pointer to data
  • Port rights may be passed in a message
  • Kernel inspects messages for particular data
    types (like port rights)

35
Mach Memory Objects
  • A source of memory accessible by tasks
  • May be managed by user-mode external memory
    manager
  • a file managed by a file server
  • Accessed by messages through a port
  • Kernel manages physical memory as cache of
    contents of memory objects

36
Mach Device Support
  • Devices represented by ports
  • Messages control the device and its data transfer
  • Actual device driver outside the kernel in an
    external object

37
Mach Multiprocessor and DS Support
  • Messages and ports can extend across
    processor/machine boundaries
  • Location transparent entities
  • Kernel manages distributed hardware
  • Per-processor data structures, but also
    structures shared across the processors
  • Intermachine messages handled by a server that
    knows about network details

38
Machs NetMsgServer
  • User-level capability-based networking daemon
  • Handles naming and transport for messages
  • Provides world-wide name service for ports
  • Messages sent to off-node ports go through this
    server

39
NetMsgServer in Action
User space
User space
User process
User process
NetMsgServer
NetMsgServer
Kernel space
Kernel space
Receiver
Sender
40
Mach and User Interfaces
  • Mach was built for the UNIX community
  • UNIX programs dont know about ports, messages,
    threads, and tasks
  • How do UNIX programs run under Mach?
  • Mach typically runs a user-level server that
    offers UNIX emulation
  • Either provides UNIX system call semantics
    internally or translates it to Mach primitives

41
Windows NT
  • More layered than some microkernel designs
  • NT Microkernel provides base services
  • Executive builds on base services via modules to
    provide user-level services
  • User-level services used by
  • privileged subsystems (parts of OS)
  • true user programs

42
Windows NT Diagram
User Processes

Protected Subsystems
User Mode
Win32
POSIX
Kernel Mode
Executive
Microkernel
Hardware
43
NT Microkernel
  • Thread scheduling
  • Process switching
  • Exception and interrupt handling
  • Multiprocessor synchronization
  • Only NT part not preemptible or pageable
  • All other NT components runs in threads

44
NT Executive
  • Higher level services than microkernel
  • Runs in kernel mode
  • but separate from the microkernel itself
  • ease of change and expansion
  • Built of independent modules
  • all preemptible and pageable

45
NT Executive Modules
  • Object manager
  • Security reference monitor
  • Process manager
  • Local procedure call facility (a la RPC)
  • Virtual memory manager
  • I/O manager

46
Typical Activity in NT

Win32 Protected Subsystem
Client Process
Executive
Kernel
Hardware
47
More On Microkernels
  • Microkernels were the research architecture of
    the 80s
  • But few commercial systems of the 90s really use
    microkernels
  • To some extent, microkernel is now a dirty word
    in OS design
  • Why?

48
Main Issue
  • What should be in the Kernel?
  • Different designs give different answers.
  • How to implement the system efficiently?
  • Some people think Micro kernel is slow
  • Micro kernel construction paper argue other way.

49
Exokernel
  • Traditional operating systems fix the interface
    and implementation of OS abstractions.
  • Abstractions must be overly general to work with
    diverse application needs.

Traditional OS
50
The Issues
  • Performance
  • Denies applications the advantages of
    domain-specific optimizations
  • Flexibility
  • Restricts the flexibility of application builders
  • Difficult or impossible to implement own resource
    management abstractions.
  • Functionality
  • Discourages changes to the implementations of
    existing abstractions since it is used by
    different applications

51
Performance
  • Example A DB can have predictable data access
    patterns, that doesn't fit with OS LRU page
    replacement, causing bad performance.
  • Cao et al. Found that application-controlled file
    caching can reduce running time by as much as
    45.
  • There is no single way to abstract physical
    resources or to implement an abstraction that is
    best for all applications.
  • OS is forced to make trade-offs
  • Performance improvements of application-specific
    policies could be substantial

52
The Solution
  • Separate protection from management
  • Allow user level to manage resources
  • Application libraries implement OS abstractions
  • Exokernel exports resources
  • Low level interface
  • Protects, does not manage
  • Expose hardware

53
Exokernel Philosophy
  • Applications know better than Operating Systems
    what the goal of their resource management
    decisions should be
  • Applications should be given as much control as
    possible over those decisions
  • Implementation view

Exokernel
Frame Buffer TLB Network Memory Disk
HW
54
Example
Exokernel Application level resource management
Exokernel
Hardware
55
Implementation Overview
  • Library O.S., which uses the low-level exokernel
    interface to implement higher-level abstractions.

Library O.S.
Exokernel
Frame Buffer TLB Network Memory Disk
HW
56
Implementation Overview
  • Applications link to library kernel, leveraging
    their higher-level abstractions.

Library O.S.
Library O.S.
Application
Application
Exokernel
Frame Buffer TLB Network Memory Disk
HW
57
End-to-End Argument
  • if something has to be done by the user program
    itself, it is wasteful to do it in a lower level
    as well.
  • Why should the OS do anything that the user
    program can do itself?
  • In other words - all an OS should do is securely
    allocate resources.

58
Exokernel design
59
Exokernel tasks
  • Track ownership
  • Guard all resources through bind points
  • Revoke access to resources
  • Abort

60
Design principle
  • Expose hardware (securely)
  • Expose allocation
  • Expose names
  • Expose revocation

61
Secure binding
  • Decouples authorization from use
  • Allows kernel to protect resource without
    understanding their semantics
  • Example TLB entry
  • Virtual to physical mapping performed in the
    library (above exokernel)
  • Binding loaded into the kernel used multiple
    times
  • Example packet filter
  • Predicates loaded into the kernel
  • Checked on each packet arrival

62
Implementing secure bindings
  • Hardware mechanisms
  • Capability for physical pages of a file
  • Frame buffer regions (SGI)
  • Software caching
  • Exokernel large software TLB overlaying the
    hardware TLB
  • Downloading code into kernel
  • Avoid expensive boundary crossings

63
Examples of secure binding
  • Physical memory allocation (hardware supported
    binding)
  • Library allocates physical page
  • Exokernel records the allocator and the
    permissions and returns a capability an
    encrypted cypher
  • Every access to this page by the library requires
    this capability
  • Page fault
  • Kernel fields it
  • Kicks it up to the library
  • Library allocated a page gets an encrypted
    capability
  • Library calls the kernel to enter a particular
    translation into the TLB
  • by presenting the capability

64
  • Download code into kernel to establish secure
    binding
  • Packet filter for demultiplexing network packets
  • How to ensure authenticity?
  • Only trusted servers (library OS) can download
    code into the kernel
  • Other use of downloaded code
  • Execute code on behalf of an app that is not
    currently scheduled
  • E.g. application handler for garbage collection
    could be installed in the kernel

65
Visible resource revocation
  • Most resources are visibly revoked
  • E.g. processor physical page
  • Library can then perform necessary action before
    relinquishing the resource
  • E.g. needed state saving for a processor
  • E.g. update of page table

66
Abort protocol
  • Repossession exception passed to the library OS
  • Repossession vector
  • Gives info to the library OS as to what was
    repossessed so that corrective action can be
    taken
  • Library OS can seed the vector to enable
    exokernel to autosave (e.g. disk blocks to which
    a physical page being repossessed should be
    written to)

67
Aegis an exokernel
68
Secure Bindings
  • Secure Binding a protection mechanism that
    decouples authorization from actual use of a
    resource
  • Allows the kernel to protect resources without
    having to understand them

69
Aegis processor time slice
  • Linear vector of time slots
  • Round robin
  • An application can mark its position in the
    vector for scheduling
  • Timer interrupt
  • Beginning and end of time slices
  • Control transferred to library specified handler
    for actual saving/restoring
  • Time to save/restore is bounded
  • Penalty? loss of a time slice next time!

70
Aegis processor environments
  • Exception context
  • Program generated
  • Interrupt context
  • External e,g. timer
  • Protected entry context
  • Cross domain calls
  • Addressing context
  • Guaranteed mappings implemented by software TLB
    mimicking the library OS page table

71
Aegis performance
Protected page
pointer
Arithmetic
72
Aegis - Address translation
  • On TLB miss
  • Kernel installs hardware from software TLB for
    guaranteed mappings
  • Otherwise application handler called
  • Application establishes mapping
  • TLB entry with associated capability presented to
    the kernel
  • Kernel installs and resumes execution of the
    application

73
ExOS library OS
  • IPC abstraction
  • VM
  • Remote communication using ASH (application
    specific safe handlers) using message.
  • Takeaway
  • significant performance improvement possible
    compared to a monolithic implementation

74
Library operating systems
  • Use the low level exokernel interface
  • Higher level abstractions
  • Special purpose implementations
  • An application can choose the library which best
    suits its needs, or even build its own.

75
Exokernel vs. Microkernel
  • A micro-kernel provides abstractions to the
    hardware such as files, sockets, graphics etc.
  • An exokernel provides almost raw access to the
    hardware.

76
Design Challenge
  • How can an Exokernel allow libOSes to freely
    manage physical resources while protecting them
    from each other?
  • Track ownership of resources
  • Secure bindings libOS can securely bind to
    machine resources
  • Guard all resource usage
  • Revoke access to resources

77
Secure Bindings
  • Exokernel allows libOSes to bind resources using
    secure bindings
  • Multiplex resources securely
  • Protection for mutually distrusted apps
  • Efficient

78
Conclusion
  • An Exokernel securely multiplexes available
    hardware raw hardware among applications
  • Application level library operating systems
    implement higher-level traditional OS
    abstractions
  • LibOSes can specialize an implementation to suit
    a particular application

79
Conclusion
  • The lower the level of a primitive
  • the more efficiently it can be implemented
  • the more latitude it gives to higher level
    abstractions
  • So, separate management from protection and
  • implement protection at a low level (exokernel)
  • implement management at a higher level (libOS)

80
Microkernel Construction
  • Most Microkernels do not perform well
  • Is it inherent in the approach or
  • Implementation?
  • IPC, microkernel bottleneck, can implemented an
    order of magnitude faster.
  • Not supervise memory
  • Minimal address space management, grant, map,
    flush.
  • Fast kernel-User Switch, usually 20-30 us but 3
    in L3 implementation

81
Micro Kernel construction
  • Microkernel should provide minimal abstractions
  • Address space, threads, IPC
  • Abstractions machine independent but
    implementation hardware dependent for performance
  • Myths about inefficiency of micro-kernel stem
    from inefficient implementation and NOT from
    microkernel approach

82
What abstractions?
  • Determining criterion
  • Functionality not performance
  • Hardware and microkernel should be trusted but
    applications are not
  • Hardware provides page-based virtual memory
  • Kernel builds on this to provide protection for
    services above and outside the microkernel
  • Principles of independence and integrity
  • Subsystems independent of one another
  • Integrity of channels between subsystems
    protected from other subsystems

83
Microkernel Concepts
  • Hardware provides address space
  • mapping from virtual page to a physical page
  • implemented by page tables and TLB
  • Microkernel concept of address spaces
  • Hides the hardware address spaces and provides an
    abstraction that supports
  • Grant?
  • Map?
  • Flush?
  • These primitives allows building a hierarchy of
    protected address spaces

84
Address spaces
Phy. Mem
R
Page table
R
A2, P2
V2, NIL
A1, P1
V1, R
Mem. Manger, process
(P1, v1)
(P1, v1)
map
A3, P3
V3, R
R
(P2, v2)
A2, P2
V2, R
(P3, v3)
(P1, v1)
flush
R
A3, P3
V3, NIL
(P2, v2)
(P1, v1)
grant
85
  • Power and flexibility of address spaces
  • Initial memory manager for address space A0
    appears by magic (outside the kernel) and
    encompasses the physical memory
  • Allow creation of stackable memory managers (all
    outside the kernel)
  • Pagers can be part of a memory manager or outside
    the memory manager
  • All address space changes (map, grant, flush)
    orchestrated via kernel for protection
  • Device driver can be implemented as a special
    memory manager outside the kernel as well

86
PT
M2, A2, P2
Map/grant
M1, A1, P1
PT
PT
M0, A0, P0
processor
Microkernel
87
Threads and IPC
  • Executes in an address space
  • PC, SP, processor registers, and state info (such
    as address space)
  • IPC is cross address space communication
  • Supported by the microkernel
  • Classic method is message passing between threads
    via the kernel
  • Sender sends info receiver decides if it wants
    to receive it, and if so where
  • Address space operations such as map, grant,
    flush need IPC
  • Higher level communication (e.g. RPC) built on
    top of basic IPC

88
  • Interrupts?
  • Each hardware device is a thread from kernels
    perspective
  • Interrupt is a null message from a hardware
    thread to the software thread
  • Kernel transforms hardware interrupt into a
    message
  • Does not know or care about the semantics of the
    interrupt
  • Device specific interrupt handling outside the
    kernel
  • Clearing hardware state (if privileged) then
    carried out by the kernel upon driver threads
    next IPC
  • TLB handler?
  • In theory software TLB handler can be outside the
    microkernel
  • In practice first level TLB handler inside the
    microkernel or in hardware

89
Unique IDs
  • Kernel provides uid over space and time for
  • Threads
  • IPC channels

90
Breaking some performance myths
  • Kernel user switches
  • Address space switches
  • Thread switches and IPC
  • Memory effects
  • Base system
  • 486 (50 MHz) 20 ns cycle time

91
Kernel-user switches
  • Machine instruction for entering and exiting
  • 107 cycles
  • Mach measures 900 cycles for kernel-user switch
  • Why?
  • Empirical proof
  • L3 kernel 123 cycles (accounting for some TLB,
    cache misses)
  • Where did the remaining 800 cycles go in MACH?
  • Kernel overhead (construction of the kernel, and
    inherent in the approach)

92
Address space switches
  • Primer on TLBs
  • AS tagged TLB (MIPS R4000) vs untagged TLB (486)
  • Untagged TLB requires flush on AS switch
  • Instruction and data caches
  • Usually physically tagged in most modern
    processors so TLB flush has no effect
  • Address space switch
  • Complete reload of Pentium TLB 864 cycles

93
  • Do we need a TLB flush always?
  • Implementation issue of protection domains
  • SPIN implements protection domains as Modula
    names within a single hardware address space
  • Liedtke suggests similar approach in the
    microkernel in an architecture-specific manner
  • PowerPC use segment registers gt no flush
  • Pentium or 486 share the linear hardware address
    space among several user address spaces gt no
    flush
  • There are some caveats in terms of size of user
    space and how many can be packed in a 232
    global space

94
  • Upshot?
  • Address space switching among medium or small
    protection domains can ALWAYS be made efficient
    by careful construction of the microkernel
  • Large address spaces switches are going to be
    expensive ALWAYS due to cache effects and TLB
    effects, so switching cost is not the most
    critical issue

95
Thread switches and IPC
96
Segment switch (instead of AS switch) makes cross
domain calls cheap
97
Memory Effects System
98
Capacity induced MCPI
99
Portability Vs. Performance
  • Microkernel on top of abstract hardware while
    portable
  • Cannot exploit hardware features
  • Cannot take precautions to avoid performance
    problems specific to an arch
  • Incurs performance penalty due to abstract layer

100
Examples of non-portability
  • Same processor family
  • Use address space switch implementation
  • TLB flush method preferable for 486
  • Segment register switch preferable for Pentium
  • gt 50 change of microkernel!
  • IPC implementation
  • Details of the cache layout (associativity)
    requires different handling of IPC buffers in 486
    and Pentium
  • Incompatible processors
  • Exokernel on R4000 (tagged TLB) Vs. 486 (untagged
    TLB)
  • gt Microkernels are inherently non-portable

101
Summary
  • Minimal set of abstractions in microkernel
  • Microkernels are processor specific (at least in
    implementation) and non-portable
  • Right abstractions and processor-specific
    implementation leads to efficient
    processor-independent abstractions at higher
    layers

102
Next Lecture
  • Process and Thread
  • Cooperative Task Management Without Manual Stack
    Management, by Atul Adya, et.al.
  • Capriccio Scalable Threads for Internet
    Services, by Ron Von Behrn, et. al.
  • The Performance Implication of Thread Management
    Alternative for Shared-Memory Multiprocessors,
    Thomas E. Anderson, et.al.
About PowerShow.com