Operating System Design, continued

• implementation issues
• operating system trends

Implementation Issues

• Structure:
  • how many pieces, and what does each do
  • how organized: layers, threads, modules -- same context (faster) or different context (safer)
  • how much to give to the user (more flexible) or retain in the kernel (single copy, so generally cheaper and faster)
• binding time: are decisions made
  • when compiling (early binding, high overhead to change but very efficient)
  • at boot/initialization time (medium)
  • at runtime (late binding, easy to change but higher overhead to use)
• checking for errors: if any error is found, must exit cleanly, so if possible check for errors before acquiring resources.
• problem: acquiring a resource may result in an error...

Performance

• can try to optimize everything, but it is more likely to lead to missing the primary goals
• performance depends on design as well as implementation: plug-and-play booting is inherently slower than booting a preconfigured system
• performance also depends on what must be implemented: fewer features mean a faster system
• it is also not unusual to select a certain design because it should allow for faster implementation

Optimization Strategies

• use a better algorithm -- better asymptotic performance, but also better constants
• space-time tradeoffs, e.g. for a function on characters, can precompute a table or can use comparisons
• caching (another space-time tradeoff) helps when values are reused. Examples: lazy programming languages, directory trees
• hints are like caches, but must be checked. Example, likely() and unlikely() declarations in the Linux kernel
• use locality, e.g. working set for processes, files within a directory
• optimize the common case: most of the exception handling can be slow, but the normal, correct path should be fast

Operating System Trends: Machine size and speed

• in 1997, I had a laptop with 4MB RAM that ran Linux just fine, but did not run Windows
• in 2004, 32 bit addressing is already limiting for high-end machines
• 64-bit addressing is the next logical step
• single-level page tables cannot be used for virtual memory with 64-bit addressing, unless the pages are very large
• with 2⁶⁴ bytes of virtual memory, objects can also be hidden in the address space -- available, but virtually inaccessible until a pointer is provided
• the entire disk (for the foreseeable future) can be mapped to the virtual address space -- could we have named storage in memory?

Operating System Trends: Distributed Operation

• while a kernel is always needed on each machine, most of the data that a machine uses may be somewhere else across a network
• to the user, this looks like the machine is just a terminal accessing data elsewhere, e.g. on the web
• making the data the focus may mean changing how we refer to named data (e.g. URLs or similar machine+localname combinations), how we design the OS (maximizing throughput may be less important than maximizing data/network access speed), refocusing on security issues, and making it natural to run code on other machines
• multiprocessors can be loosely coupled, e.g. beowulf clusters or SETI-at-home, or tightly coupled, e.g. 4-way multiprocessors, leading to very different OS issues and goals

Operating System Trends: Applications

• multimedia:
  • an OS for a home entertainment center may have very different needs than an OS for a desktop
  • or, the desktop OS might need to process applications efficiently, but also do multimedia well
  • soft real-time components
  • variety of I/O devices
  • perhaps different strategies for disk storage
• low-power computing
  • design for battery-powered computers
  • good power management needed -- current power management may be improved upon a lot
  • power management may extend to using different devices or different device modes, e.g. lower-power radio transmissions or slower CPU and disk operations, as needed
• embedded computing
  • design for low cost systems
  • may not have to be general purpose
  • example: TinyOS runs on computers with 8K of RAM and has components that can be selected according to the needs of the application

Operating System Trends: Ownership

• software can be copied for very low cost
• in an ideally efficient economy, people would be paid to develop software, and anybody could use their product
• such a scheme is hard to make practical: how do we know which software is worth developing, and how much to pay the developers?
• proprietary software: effort spent developing the OS goes to waste because fewer people use the software than would use it if it were free
• proprietary software: the developer's goals are to maximize profit (e.g. by establishing a monopoly), and these goals do not match (though they may overlap) the user's goals of maximizing their benefit
• free software: anybody can use, which maximizes the social return from the development, but minimizes the developer's return (e.g. BSD license, X license)
• open-source software: generally also free, guarantees that user will have the option of modifying and fixing their software (e.g. GPL)
• some current models to give the developers some return on their work developing free and open-source software:
  • funded like research: government or a big company sponsors the work because of the benefit to themselves (company) or to the public (government)
  • shareware: please donate if you like this product
  • bragging rights
  • sell, but without depriving others of rights to redistribute: RedHat, Mandrake
  • developers can do maintenance or special-purpose enhancements in exchange for consulting fees (amount of fees may be related to bragging rights)
• software started out as almost all open source, then became productized, and is now seeing a resurgence of open source