text:
Kernel (operating system)
From Wikipedia, the free encyclopedia
Jump to: navigation, search
"Kernel (computer science)" redirects here. It is not to be confused with Compute kernel, Kernel method, or Kernel (image processing).
"Kernel (computing)" redirects here. For other uses, see Kernel#Computing.
The kernel is a computer program that is the core of a computer's operating system, with complete control over everything in the system.[1] On most systems, it is one of the first programs loaded on start-up (after the bootloader). It handles the rest of start-up as well as input/output requests from software, translating them into data-processing instructions for the central processing unit. It handles memory and peripherals like keyboards, monitors, printers, and speakers.
A kernel connects the application software to the hardware of a computer.
The critical code of the kernel is usually loaded into a separate area of memory, which is protected from access by application programs or other, less critical parts of the operating system. The kernel performs its tasks, such as running processes, managing hardware devices such as the hard disk, and handling interrupts, in this protected kernel space. In contrast, everything a user does is in user space: writing text in a text editor, running programs in a GUI, etc. This separation prevents user data and kernel data from interfering with each other and causing instability and slowness,[1] as well as preventing malfunctioning application programs from crashing the entire operating system.
The kernel's interface is a low-level abstraction layer. When a process makes requests of the kernel, it is called a system call. Kernel designs differ in how they manage these system calls and resources. A monolithic kernel runs all the operating system instructions in the same address space for speed. A microkernel runs most processes in user space,[2] for modularity.[3]
Contents
[hide]
1 Functions
1.1 Resource Management
1.2 Memory management
1.3 Device management
1.4 System calls
2 Kernel design decisions
2.1 Issues of kernel support for protection
2.1.1 Hardware-based or language-based protection
2.2 Process cooperation
2.3 I/O devices management
3 Kernel-wide design approaches
3.1 Monolithic kernels
3.2 Microkernels
3.3 Monolithic kernels vs. microkernels
3.3.1 Performance
3.4 Hybrid (or modular) kernels
3.5 Nanokernels
3.6 Exokernels
4 History of kernel development
4.1 Early operating system kernels
4.2 Time-sharing operating systems
4.3 Amiga
4.4 Unix
4.5 Mac OS
4.6 Microsoft Windows
4.7 IBM Supervisor
4.8 Development of microkernels
5 See also
6 Notes
7 References
8 Further reading
9 External links
Functions[edit]
The kernel's primary function is to mediate access to the computer's resources, including:[4]
The central processing unit (CPU)
This central component of a computer system is responsible for running or executing programs. The kernel takes responsibility for deciding at any time which of the many running programs should be allocated to the processor or processors.
Random-access memory (RAM)
Random-access memory is used to store both program instructions and data. Typically, both need to be present in memory in order for a program to execute. Often multiple programs will want access to memory, frequently demanding more memory than the computer has available. The kernel is responsible for deciding which memory each process can use, and determining what to do when not enough memory is available.
Input/output (I/O) devices
I/O devices include such peripherals as keyboards, mice, disk drives, printers, USB devices, network adapters, and display devices. The kernel allocates requests from applications to perform I/O to an appropriate device and provides convenient methods for using the device (typically abstracted to the point where the application does not need to know implementation details of the device).
Resource Management[edit]
Key aspects necessary in resource management are the definition of an execution domain (address space) and the protection mechanism used to mediate access to the resources within a domain.[4] Kernels also provide methods for synchronization and inter-process communication (IPC). These implementations may be within the Kernel itself or the kernel can also rely on other processes it is running. Although the kernel must provide inter-process communication in order to provide access to the facilities provided by each other, kernels must also provide running programs with a method to make requests to access these facilities.
Memory management[edit]
Further information: Memory management (operating systems)
The kernel has full access to the system's memory and must allow processes to safely access this memory as they require it. Often the first step in doing this is virtual addressing, usually achieved by paging and/or segmentation. Virtual addressing allows the kernel to make a given physical address appear to be another address, the virtual address. Virtual address spaces may be different for different processes; the memory that one process accesses at a particular (virtual) address may be different memory from what another process accesses at the same address. This allows every program to behave as if it is the only one (apart from the kernel) running and thus prevents applications from crashing each other.[5]
On many systems, a program's virtual address may refer to data which is not currently in memory. The layer of indirection provided by virtual addressing allows the operating system to use other data stores, like a hard drive, to store what would otherwise have to remain in main memory (RAM). As a result, operating systems can allow programs to use more memory than the system has physically available. When a program needs data which is not currently in RAM, the CPU signals to the kernel that this has happened, and the kernel responds by writing the contents of an inactive memory block to disk (if necessary) and replacing it with the data requested by the program. The program can then be resumed from the point where it was stopped. This scheme is generally known as demand paging.
Virtual addressing also allows creation of virtual partitions of memory in two disjointed areas, one being reserved for the kernel (kernel space) and the other for the applications (user space). The applications are not permitted by the processor to address kernel memory, thus preventing an application from damaging the running kernel. This fundamental partition of memory space has contributed much to the current designs of actual general-purpose kernels and is almost universal in such systems, although some research kernels (e.g. Singularity) take other approaches.
Device management[edit]
To perform useful functions, processes need access to the peripherals connected to the computer, which are controlled by the kernel through device drivers. A device driver is a computer program that enables the operating system to interact with a hardware device. It provides the operating system with information of how to control and communicate with a certain piece of hardware. The driver is an important and vital piece to a program application. The design goal of a driver is abstraction; the function of the driver is to translate the OS-mandated function calls (programming calls) into device-specific calls. In theory, the device should work correctly with the suitable driver. Device drivers are used for such things as video cards, sound cards, printers, scanners, modems, and LAN cards. The common levels of abstraction of device drivers are:
1. On the hardware side:
Interfacing directly.
Using a high level interface (Video BIOS).
Using a lower-level device driver (file drivers using disk drivers).
Simulating work with hardware, while doing something entirely different.
2. On the software side:
Allowing the operating system direct access to hardware resources.
Implementing only primitives.
Implementing an interface for non-driver software (Example: TWAIN).
Implementing a language, sometimes high-level (Example PostScript).
For example, to show the user something on the screen, an application would make a request to the kernel, which would forward the request to its display driver, which is then responsible for actually plotting the character/pixel.[5]
A kernel must maintain a list of available devices. This list may be known in advance (e.g. on an embedded system where the kernel will be rewritten if the available hardware changes), configured by the user (typical on older PCs and on systems that are not designed for personal use) or detected by the operating system at run time (normally called plug and play). In a plug and play system, a device manager first performs a scan on different hardware buses, such as Peripheral Component Interconnect (PCI) or Universal Serial Bus (USB), to detect installed devices, then searches for the appropriate drivers.
As device management is a very OS-specific topic, these drivers are handled differently by each kind of kernel design, but in every case, the kernel has to provide the I/O to allow drivers to physically access their devices through some port or memory location. Very important decisions have to be made when designing the device management system, as in some designs accesses may involve context switches, making the operation very CPU-intensive and easily causing a significant performance overhead.[citation needed]
System calls[edit]
Main article: System call
In computing, a system call is how a process requests a service from an operating system's kernel that it does not normally have permission to run. System calls provide the interface between a process and the operating system. Most operations interacting with the system require permissions not available to a user level process, e.g. I/O performed with a device present on the system, or any form of communication with other processes requires the use of system calls.
A system call is a mechanism that is used by the application program to request a service from the operating system. They use a machine-code instruction that causes the processor to change mode. An example would be from supervisor mode to protected mode. This is where the operating system performs actions like accessing hardware devices or the memory management unit. Generally the operating system provides a library that sits between the operating system and normal programs. Usually it is a C library such as Glibc or Windows API. The library handles the low-level details of passing information to the kernel and switching to supervisor mode. System calls include close, open, read, wait and write.
To actually perform useful work, a process must be able to access the services provided by the kernel. This is implemented differently by each kernel, but most provide a C library or an API, which in turn invokes the related kernel functions.[6]
The method of invoking the kernel function varies from kernel to kernel. If memory isolation is in use, it is impossible for a user process to call the kernel directly, because that would be a violation of the processor's access control rules. A few possibilities are:
Using a software-simulated interrupt. This method is available on most hardware, and is therefore very common.
Using a call gate. A call gate is a special address stored by the kernel in a list in kernel memory at a location known to the processor. When the processor detects a call to that address, it instead redirects to the target location without causing an access violation. This requires hardware support, but the hardware for it is quite common.
Using a special system call instruction. This technique requires special hardware support, which common architectures (notably, x86) may lack. System call instructions have been added to recent models of x86 processors, however, and some operating systems for PCs make use of them when available.
Using a memory-based queue. An application that makes large numbers of requests but does not need to wait for the result of each may add details of requests to an area of memory that the kernel periodically scans to find requests.
Kernel design decisions[edit]
Issues of kernel support for protection[edit]
An important consideration in the design of a kernel is the support it provides for protection from faults (fault tolerance) and from malicious behaviours (security). These two aspects are usually not clearly distinguished, and the adoption of this distinction in the kernel design leads to the rejection of a hierarchical structure for protection.[4]
The mechanisms or policies provided by the kernel can be classified according to several criteria, including: static (enforced at compile time) or dynamic (enforced at run time); pre-emptive or post-detection; according to the protection principles they satisfy (e.g. Denning[7][8]); whether they are hardware supported or language based; whether they are more an open mechanism or a binding policy; and many more.
Support for hierarchical protection domains[9] is typically implemented using CPU modes.
Many kernels provide implementation of "capabilities", i.e. objects that are provided to user code which allow limited access to an underlying object managed by the kernel. A common example occurs in file handling: a file is a representation of information stored on a permanent storage device. The kernel may be able to perform many different operations (e.g. read, write, delete or execute the file contents) but a user level application may only be permitted to perform some of these operations (e.g. it may only be allowed to read the file). A common implementation of this is for the kernel to provide an object to the application (typically called a "file handle") which the application may then invoke operations on, the validity of which the kernel checks at the time the operation is requested. Such a system may be extended to cover all objects that the kernel manages, and indeed to objects provided by other user applications.
An efficient and simple way to provide hardware support of capabilities is to delegate the MMU the responsibility of checking access-rights for every memory access, a mechanism called capability-based addressing.[10] Most commercial computer architectures lack such MMU support for capabilities.
An alternative approach is to simulate capabilities using commonly supported hierarchical domains; in this approach, each protected object must reside in an address space that the application does not have access to; the kernel also maintains a list of capabilities in such memory. When an application needs to access an object protected by a capability, it performs a system call and the kernel then checks whether the application's capability grants it permission to perform the requested action, and if it is permitted performs the access for it (either directly, or by delegating the request to another user-level process). The performance cost of address space switching limits the practicality of this approach in systems with complex interactions between objects, but it is used in current operating systems for objects that are not accessed frequently or which are not expected to perform quickly.[11][12] Approaches where protection mechanism are not firmware supported but are instead simulated at higher levels (e.g. simulating capabilities by manipulating page tables on hardware that does not have direct support), are possible, but there are performance implications.[13] Lack of hardware support may not be an issue, however, for systems that choose to use language-based protection.[14]
An important kernel design decision is the choice of the abstraction levels where the security mechanisms and policies should be implemented. Kernel security mechanisms play a critical role in supporting security at higher levels.[10][15][16][17][18]
One approach is to use firmware and kernel support for fault tolerance (see above), and build the security policy for malicious behavior on top of that (adding features such as cryptography mechanisms where necessary), delegating some responsibility to the compiler. Approaches that delegate enforcement of security policy to the compiler and/or the application level are often called language-based security.
The lack of many critical security mechanisms in current mainstream operating systems impedes the implementation of adequate security policies at the application abstraction level.[15] In fact, a common misconception in computer security is that any security policy can be implemented in an application regardless of kernel support.[15]
Hardware-based or language-based protection[edit]
Typical computer systems today use hardware-enforced rules about what programs are allowed to access what data. The processor monitors the execution and stops a program that violates a rule (e.g., a user process that is about to read or write to kernel memory, and so on). In systems that lack support for capabilities, processes are isolated from each other by using separate address spaces.[19] Calls from user processes into the kernel are regulated by requiring them to use one of the above-described system call methods.
An alternative approach is to use language-based protection. In a language-based protection system, the kernel will only allow code to execute that has been produced by a trusted language compiler. The language may then be designed such that it is impossible for the programmer to instruct it to do something that will violate a security requirement.[14]
Advantages of this approach include:
No need for separate address spaces. Switching between address spaces is a slow operation that causes a great deal of overhead, and a lot of optimization work is currently performed in order to prevent unnecessary switches in current operating systems. Switching is completely unnecessary in a language-based protection system, as all code can safely operate in the same address space.
Flexibility. Any protection scheme that can be designed to be expressed via a programming language can be implemented using this method. Changes to the protection scheme (e.g. from a hierarchical system to a capability-based one) do not require new hardware.
Disadvantages include:
Longer application start up time. Applications must be verified when they are started to ensure they have been compiled by the correct compiler, or may need recompiling either from source code or from bytecode.
Inflexible type systems. On traditional systems, applications frequently perform operations that are not type safe. Such operations cannot be permitted in a language-based protection system, which means that applications may need to be rewritten and may, in some cases, lose performance.
Examples of systems with language-based protection include JX and Microsoft's Singularity.
Process cooperation[edit]
Edsger Dijkstra proved that from a logical point of view, atomic lock and unlock operations operating on binary semaphores are sufficient primitives to express any functionality of process cooperation.[20] However this approach is generally held to be lacking in terms of safety and efficiency, whereas a message passing approach is more flexible.[21] A number of other approaches (either lower- or higher-level) are available as well, with many modern kernels providing support for systems such as shared memory and remote procedure calls.
I/O devices management[edit]
The idea of a kernel where I/O devices are handled uniformly with other processes, as parallel co-operating processes, was first proposed and implemented by Brinch Hansen (although similar ideas were suggested in 1967[22][23]). In Hansen's description of this, the "common" processes are called internal processes, while the I/O devices are called external processes.[21]
Similar to physical memory, allowing applications direct access to controller ports and registers can cause the controller to malfunction, or system to crash. With this, depending on the complexity of the device, some devices can get surprisingly complex to program, and use several different controllers. Because of this, providing a more abstract interface to manage the device is important. This interface is normally done by a Device Driver or Hardware Abstraction Layer. Frequently, applications will require access to these devices. The Kernel must maintain the list of these devices by querying the system for them in some way. This can be done through the BIOS, or through one of the various system buses (such as PCI/PCIE, or USB). When an application requests an operation on a device (Such as displaying a character), the kernel needs to send this request to the current active video driver. The video driver, in turn, needs to carry out this request. This is an example of Inter Process Communication (IPC).
Kernel-wide design approaches[edit]
Naturally, the above listed tasks and features can be provided in many ways that differ from each other in design and implementation.
The principle of separation of mechanism and policy is the substantial difference between the philosophy of micro and monolithic kernels.[24][25] Here a mechanism is the support that allows the implementation of many different policies, while a policy is a particular "mode of operation". For instance, a mechanism may provide for user log-in attempts to call an authorization server to determine whether access should be granted; a policy may be for the authorization server to request a password and check it against an encrypted password stored in a database. Because the mechanism is generic, the policy could more easily be changed (e.g. by requiring the use of a security token) than if the mechanism and policy were integrated in the same module.
In minimal microkernel just some very basic policies are included,[25] and its mechanisms allows what is running on top of the kernel (the remaining part of the operating system and the other applications) to decide which policies to adopt (as memory management, high level process scheduling, file system management, etc.).[4][21] A monolithic kernel instead tends to include many policies, therefore restricting the rest of the system to rely on them.
Per Brinch Hansen presented arguments in favour of separation of mechanism and policy.[4][21] The failure to properly fulfill this separation is one of the major causes of the lack of substantial innovation in existing operating systems,[4] a problem common in computer architecture.[26][27][28] The monolithic design is induced by the "kernel mode"/"user mode" architectural approach to protection (technically called hierarchical protection domains), which is common in conventional commercial systems;[29] in fact, every module needing protection is therefore preferably included into the kernel.[29] This link between monolithic design and "privileged mode" can be reconducted to the key issue of mechanism-policy separation;[4] in fact the "privileged mode" architectural approach melts together the protection mechanism with the security policies, while the major alternative architectural approach, capability-based addressing, clearly distinguishes between the two, leading naturally to a microkernel design[4] (see Separation of protection and security).
While monolithic kernels execute all of their code in the same address space (kernel space), microkernels try to run most of their services in user space, aiming to improve maintainability and modularity of the codebase.[30] Most kernels do not fit exactly into one of these categories, but are rather found in between these two designs. These are called hybrid kernels. More exotic designs such as nanokernels and exokernels are available, but are seldom used for production systems. The Xen hypervisor, for example, is an exokernel.
Monolithic kernels[edit]
Main article: Monolithic kernel
Diagram of a monolithic kernel
In a monolithic kernel, all OS services run along with the main kernel thread, thus also residing in the same memory area. This approach provides rich and powerful hardware access. Some developers, such as UNIX developer Ken Thompson, maintain that it is "easier to implement a monolithic kernel"[31] than microkernels. The main disadvantages of monolithic kernels are the dependencies between system components – a bug in a device driver might crash the entire system – and the fact that large kernels can become very difficult to maintain.
Monolithic kernels, which have traditionally been used by Unix-like operating systems, contain all the operating system core functions and the device drivers. This is the traditional design of UNIX systems. A monolithic kernel is one single program that contains all of the code necessary to perform every kernel related task. Every part which is to be accessed by most programs which cannot be put in a library is in the kernel space: Device drivers, Scheduler, Memory handling, File systems, Network stacks. Many system calls are provided to applications, to allow them to access all those services. A monolithic kernel, while initially loaded with subsystems that may not be needed, can be tuned to a point where it is as fast as or faster than the one that was specifically designed for the hardware, although more relevant in a general sense. Modern monolithic kernels, such as those of Linux and FreeBSD, both of which fall into the category of Unix-like operating systems, feature the ability to load modules at runtime, thereby allowing easy extension of the kernel's capabilities as required, while helping to minimize the amount of code running in kernel space. In the monolithic kernel, some advantages hinge on these points:
Since there is less software involved it is faster.
As it is one single piece of software it should be smaller both in source and compiled forms.
Less code generally means fewer bugs which can translate to fewer security problems.
Most work in the monolithic kernel is done via system calls. These are interfaces, usually kept in a tabular structure, that access some subsystem within the kernel such as disk operations. Essentially calls are made within programs and a checked copy of the request is passed through the system call. Hence, not far to travel at all. The monolithic Linux kernel can be made extremely small not only because of its ability to dynamically load modules but also because of its ease of customization. In fact, there are some versions that are small enough to fit together with a large number of utilities and other programs on a single floppy disk and still provide a fully functional operating system (one of the most popular of which is muLinux). This ability to miniaturize its kernel has also led to a rapid growth in the use of Linux in embedded systems.
These types of kernels consist of the core functions of the operating system and the device drivers with the ability to load modules at runtime. They provide rich and powerful abstractions of the underlying hardware. They provide a small set of simple hardware abstractions and use applications called servers to provide more functionality. This particular approach defines a high-level virtual interface over the hardware, with a set of system calls to implement operating system services such as process management, concurrency and memory management in several modules that run in supervisor mode. This design has several flaws and limitations:
Coding in kernel can be challenging, in part because one cannot use common libraries (like a full-featured libc), and because one needs to use a source-level debugger like gdb. Rebooting the computer is often required. This is not just a problem of convenience to the developers. When debugging is harder, and as difficulties become stronger, it becomes more likely that code will be "buggier".
Bugs in one part of the kernel have strong side effects; since every function in the kernel has all the privileges, a bug in one function can corrupt data structure of another, totally unrelated part of the kernel, or of any running program.
Kernels often become very large and difficult to maintain.
Even if the modules servicing these operations are separate from the whole, the code integration is tight and difficult to do correctly.
Since the modules run in the same address space, a bug can bring down the entire system.
Monolithic kernels are not portable; therefore, they must be rewritten for each new architecture that the operating system is to be used on.
In the microkernel approach, the kernel itself only provides basic functionality that allows the execution of servers, separate programs that assume former kernel functions, such as device drivers, GUI servers, etc.
Microkernels[edit]
Main article: Microkernel
Microkernel (also abbreviated μK or uK) is the term describing an approach to operating system design by which the functionality of the system is moved out of the traditional "kernel", into a set of "servers" that communicate through a "minimal" kernel, leaving as little as possible in "system space" and as much as possible in "user space". A microkernel that is designed for a specific platform or device is only ever going to have what it needs to operate. The microkernel approach consists of defining a simple abstraction over the hardware, with a set of primitives or system calls to implement minimal OS services such as memory management, multitasking, and inter-process communication. Other services, including those normally provided by the kernel, such as networking, are implemented in user-space programs, referred to as servers. Microkernels are easier to maintain than monolithic kernels, but the large number of system calls and context switches might slow down the system because they typically generate more overhead than plain function calls.
Only parts which really require being in a privileged mode are in kernel space: IPC (Inter-Process Communication), basic scheduler, or scheduling primitives, basic memory handling, basic I/O primitives. Many critical parts are now running in user space: The complete scheduler, memory handling, file systems, and network stacks. Micro kernels were invented as a reaction to traditional "monolithic" kernel design, whereby all system functionality was put in a one static program running in a special "system" mode of the processor. In the microkernel, only the most fundamental of tasks are performed such as being able to access some (not necessarily all) of the hardware, manage memory and coordinate message passing between the processes. Some systems that use micro kernels are QNX and the HURD. In the case of QNX and Hurd user sessions can be entire snapshots of the system itself or views as it is referred to. The very essence of the microkernel architecture illustrates some of its advantages:
Maintenance is generally easier.
Patches can be tested in a separate instance, and then swapped in to take over a production instance.
Rapid development time and new software can be tested without having to reboot the kernel.
More persistence in general, if one instance goes hay-wire, it is often possible to substitute it with an operational mirror.
Most micro kernels use a message passing system of some sort to handle requests from one server to another. The message passing system generally operates on a port basis with the microkernel. As an example, if a request for more memory is sent, a port is opened with the microkernel and the request sent through. Once within the microkernel, the steps are similar to system calls. The rationale was that it would bring modularity in the system architecture, which would entail a cleaner system, easier to debug or dynamically modify, customizable to users' needs, and more performing. They are part of the operating systems like AIX, BeOS, Hurd, Mach, macOS, MINIX, QNX. Etc. Although micro kernels are very small by themselves, in combination with all their required auxiliary code they are, in fact, often larger than monolithic kernels. Advocates of monolithic kernels also point out that the two-tiered structure of microkernel systems, in which most of the operating system does not interact directly with the hardware, creates a not-insignificant cost in terms of system efficiency. These types of kernels normally provide only the minimal services such as defining memory address spaces, Inter-process communication (IPC) and the process management. The other functions such as running the hardware processes are not handled directly by micro kernels. Proponents of micro kernels point out those monolithic kernels have the disadvantage that an error in the kernel can cause the entire system to crash. However, with a microkernel, if a kernel process crashes, it is still possible to prevent a crash of the system as a whole by merely restarting the service that caused the error.
Other services provided by the kernel such as networking are implemented in user-space programs referred to as servers. Servers allow the operating system to be modified by simply starting and stopping programs. For a machine without networking support, for instance, the networking server is not started. The task of moving in and out of the kernel to move data between the various applications and servers creates overhead which is detrimental to the efficiency of micro kernels in comparison with monolithic kernels.
Disadvantages in the microkernel exist however. Some are:
Larger running memory footprint
More software for interfacing is required, there is a potential for performance loss.
Messaging bugs can be harder to fix due to the longer trip they have to take versus the one off copy in a monolithic kernel.
Process management in general can be very complicated.
The disadvantages for micro kernels are extremely context based. As an example, they work well for small single purpose (and critical) systems because if not many processes need to run, then the complications of process management are effectively mitigated.
A microkernel allows the implementation of the remaining part of the operating system as a normal application program written in a high-level language, and the use of different operating systems on top of the same unchanged kernel.[21] It is also possible to dynamically switch among operating systems and to have more than one active simultaneously.[21]
Monolithic kernels vs. microkernels[edit]
As the computer kernel grows, so grows the size and vulnerability of its trusted computing base; and, besides reducing security, there is the problem of enlarging the memory footprint. This is mitigated to some degree by perfecting the virtual memory system, but not all computer architectures have virtual memory support.[32] To reduce the kernel's footprint, extensive editing has to be performed to carefully remove unneeded code, which can be very difficult with non-obvious interdependencies between parts of a kernel with millions of lines of code.
By the early 1990s, due to the various shortcomings of monolithic kernels versus microkernels, monolithic kernels were considered obsolete by virtually all operating system researchers.[citation needed] As a result, the design of Linux as a monolithic kernel rather than a microkernel was the topic of a famous debate between Linus Torvalds and Andrew Tanenbaum.[33] There is merit on both sides of the argument presented in the Tanenbaum–Torvalds debate.
Performance[edit]
Monolithic kernels are designed to have all of their code in the same address space (kernel space), which some developers argue is necessary to increase the performance of the system.[34] Some developers also maintain that monolithic systems are extremely efficient if well written.[34] The monolithic model tends to be more efficient[35] through the use of shared kernel memory, rather than the slower IPC system of microkernel designs, which is typically based on message passing.[citation needed]
The performance of microkernels was poor in both the 1980s and early 1990s.[36][37] However, studies that empirically measured the performance of these microkernels did not analyze the reasons of such inefficiency.[36] The explanations of this data were left to "folklore", with the assumption that they were due to the increased frequency of switches from "kernel-mode" to "user-mode",[36] to the increased frequency of inter-process communication[36] and to the increased frequency of context switches.[36]
In fact, as guessed in 1995, the reasons for the poor performance of microkernels might as well have been: (1) an actual inefficiency of the whole microkernel approach, (2) the particular concepts implemented in those microkernels, and (3) the particular implementation of those concepts.[36] Therefore it remained to be studied if the solution to build an efficient microkernel was, unlike previous attempts, to apply the correct construction techniques.[36]
On the other end, the hierarchical protection domains architecture that leads to the design of a monolithic kernel[29] has a significant performance drawback each time there's an interaction between different levels of protection (i.e. when a process has to manipulate a data structure both in 'user mode' and 'supervisor mode'), since this requires message copying by value.[38]
By the mid-1990s, most researchers had abandoned the belief that careful tuning could reduce this overhead dramatically,[citation needed] but recently, newer microkernels, optimized for performance, such as L4[39] and K42 have addressed these problems.[verification needed]
The hybrid kernel approach combines the speed and simpler design of a monolithic kernel with the modularity and execution safety of a microkernel.
Hybrid (or modular) kernels[edit]
Main article: Hybrid kernel
Hybrid kernels are used in most commercial operating systems such as Microsoft Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, XP, Vista, 7, 8, 8.1 and 10. Apple Inc's own macOS uses a hybrid kernel called XNU which is based upon code from OSF/1's Mach kernel (OSFMK 7.3)[40] and FreeBSD's monolithic kernel. They are similar to micro kernels, except they include some additional code in kernel-space to increase performance. These kernels represent a compromise that was implemented by some developers before it was demonstrated that pure micro kernels can provide high performance. These types of kernels are extensions of micro kernels with some properties of monolithic kernels. Unlike monolithic kernels, these types of kernels are unable to load modules at runtime on their own. Hybrid kernels are micro kernels that have some "non-essential" code in kernel-space in order for the code to run more quickly than it would were it to be in user-space. Hybrid kernels are a compromise between the monolithic and microkernel designs. This implies running some services (such as the network stack or the filesystem) in kernel space to reduce the performance overhead of a traditional microkernel, but still running kernel code (such as device drivers) as servers in user space.
Many traditionally monolithic kernels are now at least adding (if not actively exploiting) the module capability. The most well known of these kernels is the Linux kernel. The modular kernel essentially can have parts of it that are built into the core kernel binary or binaries that load into memory on demand. It is important to note that a code tainted module has the potential to destabilize a running kernel. Many people become confused on this point when discussing micro kernels. It is possible to write a driver for a microkernel in a completely separate memory space and test it before "going" live. When a kernel module is loaded, it accesses the monolithic portion's memory space by adding to it what it needs, therefore, opening the doorway to possible pollution. A few advantages to the modular (or) Hybrid kernel are:
Faster development time for drivers that can operate from within modules. No reboot required for testing (provided the kernel is not destabilized).
On demand capability versus spending time recompiling a whole kernel for things like new drivers or subsystems.
Faster integration of third party technology (related to development but pertinent unto itself nonetheless).
Modules, generally, communicate with the kernel using a module interface of some sort. The interface is generalized (although particular to a given operating system) so it is not always possible to use modules. Often the device drivers may need more flexibility than the module interface affords. Essentially, it is two system calls and often the safety checks that only have to be done once in the monolithic kernel now may be done twice. Some of the disadvantages of the modular approach are:
With more interfaces to pass through, the possibility of increased bugs exists (which implies more security holes).
Maintaining modules can be confusing for some administrators when dealing with problems like symbol differences.
Nanokernels[edit]
Main article: Nanokernel
A nanokernel delegates virtually all services – including even the most basic ones like interrupt controllers or the timer – to device drivers to make the kernel memory requirement even smaller than a traditional microkernel.[41]
Exokernels[edit]
Main article: Exokernel
Exokernels are a still-experimental approach to operating system design. They differ from the other types of kernels in that their functionality is limited to the protection and multiplexing of the raw hardware, providing no hardware abstractions on top of which to develop applications. This separation of hardware protection from hardware management enables application developers to determine how to make the most efficient use of the available hardware for each specific program.
Exokernels in themselves are extremely small. However, they are accompanied by library operating systems (see also unikernel), providing application developers with the functionalities of a conventional operating system. A major advantage of exokernel-based systems is that they can incorporate multiple library operating systems, each exporting a different API, for example one for high level UI development and one for real-time control.
History of kernel development[edit]
Early operating system kernels[edit]
Main article: History of operating systems
Strictly speaking, an operating system (and thus, a kernel) is not required to run a computer. Programs can be directly loaded and executed on the "bare metal" machine, provided that the authors of those programs are willing to work without any hardware abstraction or operating system support. Most early computers operated this way during the 1950s and early 1960s, which were reset and reloaded between the execution of different programs. Eventually, small ancillary programs such as program loaders and debuggers were left in memory between runs, or loaded from ROM. As these were developed, they formed the basis of what became early operating system kernels. The "bare metal" approach is still used today on some video game consoles and embedded systems,[42] but in general, newer computers use modern operating systems and kernels.
In 1969, the RC 4000 Multiprogramming System introduced the system design philosophy of a small nucleus "upon which operating systems for different purposes could be built in an orderly manner",[43] what would be called the microkernel approach.
Time-sharing operating systems[edit]
Main article: Time-sharing
In the decade preceding Unix, computers had grown enormously in power – to the point where computer operators were looking for new ways to get people to use their spare time on their machines. One of the major developments during this era was time-sharing, whereby a number of users would get small slices of computer time, at a rate at which it appeared they were each connected to their own, slower, machine.[44]
The development of time-sharing systems led to a number of problems. One was that users, particularly at universities where the systems were being developed, seemed to want to hack the system to get more CPU time. For this reason, security and access control became a major focus of the Multics project in 1965.[45] Another ongoing issue was properly handling computing resources: users spent most of their time staring at the terminal and thinking about what to input instead of actually using the resources of the computer, and a time-sharing system should give the CPU time to an active user during these periods. Finally, the systems typically offered a memory hierarchy several layers deep, and partitioning this expensive resource led to major developments in virtual memory systems.
Amiga[edit]
Main article: AmigaOS
The Commodore Amiga was released in 1985, and was among the first – and certainly most successful – home computers to feature an advanced kernel architecture. The AmigaOS kernel's executive component, exec.library, uses a microkernel message-passing design, but there are other kernel components, like graphics.library, that have direct access to the hardware. There is no memory protection, and the kernel is almost always running in user mode. Only special actions are executed in kernel mode, and user-mode applications can ask the operating system to execute their code in kernel mode.
Unix[edit]
Main article: Unix
A diagram of the predecessor/successor family relationship for Unix-like systems
During the design phase of Unix, programmers decided to model every high-level device as a file, because they believed the purpose of computation was data transformation.[46]
For instance, printers were represented as a "file" at a known location – when data was copied to the file, it printed out. Other systems, to provide a similar functionality, tended to virtualize devices at a lower level – that is, both devices and files would be instances of some lower level concept. Virtualizing the system at the file level allowed users to manipulate the entire system using their existing file management utilities and concepts, dramatically simplifying operation. As an extension of the same paradigm, Unix allows programmers to manipulate files using a series of small programs, using the concept of pipes, which allowed users to complete operations in stages, feeding a file through a chain of single-purpose tools. Although the end result was the same, using smaller programs in this way dramatically increased flexibility as well as ease of development and use, allowing the user to modify their workflow by adding or removing a program from the chain.
In the Unix model, the operating system consists of two parts; first, the huge collection of utility programs that drive most operations, the other the kernel that runs the programs.[46] Under Unix, from a programming standpoint, the distinction between the two is fairly thin; the kernel is a program, running in supervisor mode,[47] that acts as a program loader and supervisor for the small utility programs making up the rest of the system, and to provide locking and I/O services for these programs; beyond that, the kernel didn't intervene at all in user space.
Over the years the computing model changed, and Unix's treatment of everything as a file or byte stream no longer was as universally applicable as it was before. Although a terminal could be treated as a file or a byte stream, which is printed to or read from, the same did not seem to be true for a graphical user interface. Networking posed another problem. Even if network communication can be compared to file access, the low-level packet-oriented architecture dealt with discrete chunks of data and not with whole files. As the capability of computers grew, Unix became increasingly cluttered with code. It is also because the modularity of the Unix kernel is extensively scalable.[48] While kernels might have had 100,000 lines of code in the seventies and eighties, kernels of modern Unix successors like Linux have more than 13 million lines.[49]
Modern Unix-derivatives are generally based on module-loading monolithic kernels. Examples of this are the Linux kernel in its many distributions as well as the Berkeley Software Distribution variant kernels such as FreeBSD, DragonflyBSD, OpenBSD, NetBSD,and macOS. Apart from these alternatives, amateur developers maintain an active operating system development community, populated by self-written hobby kernels which mostly end up sharing many features with Linux, FreeBSD, DragonflyBSD, OpenBSD or NetBSD kernels and/or being compatible with them.[50]
Mac OS[edit]
Main articles: Classic Mac OS and macOS
Apple first launched its classic Mac OS in 1984, bundled with its Macintosh personal computer. Apple moved to a nanokernel design in Mac OS 8.6. Against this, the modern macOS (originally named Mac OS X) is based on Darwin, which uses a hybrid kernel called XNU, which was created by combining the 4.3BSD kernel and the Mach kernel.[51]
Microsoft Windows[edit]
Main article: History of Microsoft Windows
Microsoft Windows was first released in 1985 as an add-on to MS-DOS. Because of its dependence on another operating system, initial releases of Windows, prior to Windows 95, were considered an operating environment (not to be confused with an operating system). This product line continued to evolve through the 1980s and 1990s, with the Windows 9x series adding 32-bit addressing and pre-emptive multitasking; but ended with the release of Windows Me in 2000.
Microsoft also developed Windows NT, an operating system with a very similar interface, but intended for high-end and business users. This line started with the release of Windows NT 3.1 in 1993, and was introduced to general users with the release of Windows XP in October 2001—replacing Windows 9x with a completely different, much more sophisticated operating system. This is the line that continues with Windows 10.
The architecture of Windows NT's kernel is considered a hybrid kernel because the kernel itself contains tasks such as the Window Manager and the IPC Managers, with a client/server layered subsystem model.[52]
IBM Supervisor[edit]
Supervisory program or supervisor is a computer program, usually part of an operating system, that controls the execution of other routines and regulates work scheduling, input/output operations, error actions, and similar functions and regulates the flow of work in a data processing system.
Historically, this term was essentially associated with IBM's line of mainframe operating systems starting with OS/360. In other operating systems, the supervisor is generally called the kernel.
In the 1970s, IBM further abstracted the supervisor state from the hardware, resulting in a hypervisor that enabled full virtualization, i.e. the capacity to run multiple operating systems on the same machine totally independently from each other. Hence the first such system was called Virtual Machine or VM.
Development of microkernels[edit]
Although Mach, developed at Carnegie Mellon University from 1985 to 1994, is the best-known general-purpose microkernel, other microkernels have been developed with more specific aims. The L4 microkernel family (mainly the L3 and the L4 kernel) was created to demonstrate that microkernels are not necessarily slow.[39] Newer implementations such as Fiasco and Pistachio are able to run Linux next to other L4 processes in separate address spaces.[53][54]
Additionally, QNX is a microkernel which is principally used in embedded systems,[55] and the open-source software MINIX, while originally created for educational purposes, is now focussed on being a highly reliable and self-healing microkernel OS.
See also[edit]
Comparison of operating system kernels
Inter-process communication
Notes[edit]
^ Jump up to: a b "Kernel". Linfo. Bellevue Linux Users Group. Retrieved 15 September 2016.
Jump up ^ cf. Daemon (computing)
Jump up ^ Roch 2004
^ Jump up to: a b c d e f g h Wulf 1974 pp.337–345
^ Jump up to: a b Silberschatz 1991
Jump up ^ Tanenbaum, Andrew S. (2008). Modern Operating Systems (3rd ed.). Prentice Hall. pp. 50–51. ISBN 0-13-600663-9. . . . nearly all system calls [are] invoked from C programs by calling a library procedure . . . The library procedure . . . executes a TRAP instruction to switch from user mode to kernel mode and start execution . . .
Jump up ^ Denning 1976
Jump up ^ Swift 2005, p.29 quote: "isolation, resource control, decision verification (checking), and error recovery."
Jump up ^ Schroeder 72
^ Jump up to: a b Linden 76
Jump up ^ Stephane Eranian and David Mosberger, Virtual Memory in the IA-64 Linux Kernel, Prentice Hall PTR, 2002
Jump up ^ Silberschatz & Galvin, Operating System Concepts, 4th ed, pp. 445 & 446
Jump up ^ Hoch, Charles; J. C. Browne (July 1980). "An implementation of capabilities on the PDP-11/45" (PDF). ACM SIGOPS Operating Systems Review. 14 (3): 22–32. doi:10.1145/850697.850701. Retrieved 2007-01-07.
^ Jump up to: a b A Language-Based Approach to Security, Schneider F., Morrissett G. (Cornell University) and Harper R. (Carnegie Mellon University)
^ Jump up to: a b c P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments Archived 2007-06-21 at the Wayback Machine.. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, Oct. 1998. [1].
Jump up ^ J. Lepreau et al. The Persistent Relevance of the Local Operating System to Global Applications. Proceedings of the 7th ACM SIGOPS Eurcshelf/book001/book001.html Information Security: An Integrated Collection of Essays, IEEE Comp. 1995.
Jump up ^ J. Anderson, Computer Security Technology Planning Study, Air Force Elect. Systems Div., ESD-TR-73-51, October 1972.
Jump up ^ * Jerry H. Saltzer; Mike D. Schroeder (September 1975). "The protection of information in computer systems". Proceedings of the IEEE. 63 (9): 1278–1308. doi:10.1109/PROC.1975.9939.
Jump up ^ Jonathan S. Shapiro; Jonathan M. Smith; David J. Farber (1999). "EROS: a fast capability system". Proceedings of the seventeenth ACM symposium on Operating systems principles. 33 (5): 170–185. doi:10.1145/319344.319163.
Jump up ^ Dijkstra, E. W. Cooperating Sequential Processes. Math. Dep., Technological U., Eindhoven, Sept. 1965.
^ Jump up to: a b c d e f Brinch Hansen 70 pp.238–241
Jump up ^ "SHARER, a time sharing system for the CDC 6600". Retrieved 2007-01-07.
Jump up ^ "Dynamic Supervisors – their design and construction". Retrieved 2007-01-07.
Jump up ^ Baiardi 1988
^ Jump up to: a b Levin 75
Jump up ^ Denning 1980
Jump up ^ Jürgen Nehmer The Immortality of Operating Systems, or: Is Research in Operating Systems still Justified? Lecture Notes In Computer Science; Vol. 563. Proceedings of the International Workshop on Operating Systems of the 90s and Beyond. pp. 77–83 (1991) ISBN 3-540-54987-0 [2] quote: "The past 25 years have shown that research on operating system architecture had a minor effect on existing main stream [sic] systems."
Jump up ^ Levy 84, p.1 quote: "Although the complexity of computer applications increases yearly, the underlying hardware architecture for applications has remained unchanged for decades."
^ Jump up to: a b c Levy 84, p.1 quote: "Conventional architectures support a single privileged mode of operation. This structure leads to monolithic design; any module needing protection must be part of the single operating system kernel. If, instead, any module could execute within a protected domain, systems could be built as a collection of independent modules extensible by any user."
Jump up ^ Roch 2004
Jump up ^ Open Sources: Voices from the Open Source Revolution
Jump up ^ Virtual addressing is most commonly achieved through a built-in memory management unit.
Jump up ^ Recordings of the debate between Torvalds and Tanenbaum can be found at dina.dk Archived 2012-10-03 at the Wayback Machine., groups.google.com, oreilly.com and Andrew Tanenbaum's website
^ Jump up to: a b Matthew Russell. "What Is Darwin (and How It Powers Mac OS X)". O'Reilly Media. quote: "The tightly coupled nature of a monolithic kernel allows it to make very efficient use of the underlying hardware [...] Microkernels, on the other hand, run a lot more of the core processes in userland. [...] Unfortunately, these benefits come at the cost of the microkernel having to pass a lot of information in and out of the kernel space through a process known as a context switch. Context switches introduce considerable overhead and therefore result in a performance penalty."
Jump up ^ Operating Systems/Kernel Models
^ Jump up to: a b c d e f g Liedtke 95
Jump up ^ Härtig 97
Jump up ^ Hansen 73, section 7.3 p.233 "interactions between different levels of protection require transmission of messages by value"
^ Jump up to: a b The L4 microkernel family – Overview
Jump up ^ https://www.youtube.com/watch?v=ggnFoDqzGMU
Jump up ^ KeyKOS Nanokernel Architecture Archived 2011-06-21 at the Wayback Machine.
Jump up ^ Ball: Embedded Microprocessor Designs, p. 129
Jump up ^ Hansen 2001 (os), pp.17–18
Jump up ^ BSTJ version of C.ACM Unix paper
Jump up ^ Introduction and Overview of the Multics System, by F. J. Corbató and V. A. Vissotsky.
^ Jump up to: a b "The Single Unix Specification". The open group.
Jump up ^ The highest privilege level has various names throughout different architectures, such as supervisor mode, kernel mode, CPL0, DPL0, ring 0, etc. See Ring (computer security) for more information.
Jump up ^ Unix's Revenge by Horace Dediu
Jump up ^ Linux Kernel 2.6: It's Worth More!, by David A. Wheeler, October 12, 2004
Jump up ^ This community mostly gathers at Bona Fide OS Development, The Mega-Tokyo Message Board and other operating system enthusiast web sites.
Jump up ^ XNU: The Kernel Archived 2011-08-22 at WebCite
Jump up ^ Windows History: Windows Desktop Products History
Jump up ^ The Fiasco microkernel – Overview
Jump up ^ L4Ka – The L4 microkernel family and friends
Jump up ^ QNX Realtime Operating System Overview
References[edit]
Roch, Benjamin (2004). "Monolithic kernel vs. Microkernel" (PDF). Archived from the original (PDF) on 2006-11-01. Retrieved 2006-10-12.
Silberschatz, Abraham; James L. Peterson; Peter B. Galvin (1991). Operating system concepts. Boston, Massachusetts: Addison-Wesley. p. 696. ISBN 0-201-51379-X.
Ball, Stuart R. (2002) [2002]. Embedded Microprocessor Systems: Real World Designs (first ed.). Elsevier Science. ISBN 0-7506-7534-9.
Deitel, Harvey M. (1984) [1982]. An introduction to operating systems (revisited first ed.). Addison-Wesley. p. 673. ISBN 0-201-14502-2.
Denning, Peter J. (December 1976). "Fault tolerant operating systems". ACM Computing Surveys. 8 (4): 359–389. doi:10.1145/356678.356680. ISSN 0360-0300.
Denning, Peter J. (April 1980). "Why not innovations in computer architecture?". ACM SIGARCH Computer Architecture News. 8 (2): 4–7. doi:10.1145/859504.859506. ISSN 0163-5964.
Hansen, Per Brinch (April 1970). "The nucleus of a Multiprogramming System". Communications of the ACM. 13 (4): 238–241. doi:10.1145/362258.362278. ISSN 0001-0782.
Hansen, Per Brinch (1973). Operating System Principles. Englewood Cliffs: Prentice Hall. p. 496. ISBN 0-13-637843-9.
Hansen, Per Brinch (2001). "The evolution of operating systems" (PDF). Retrieved 2006-10-24. included in book: Per Brinch Hansen, ed. (2001). "1" (PDF). Classic operating systems: from batch processing to distributed systems. New York,: Springer-Verlag. pp. 1–36. ISBN 0-387-95113-X.
Hermann Härtig, Michael Hohmuth, Jochen Liedtke, Sebastian Schönberg, Jean Wolter The performance of μ-kernel-based systems, Härtig, Hermann; Hohmuth, Michael; Liedtke, Jochen; Schönberg, Sebastian (1997). "The performance of μ-kernel-based systems". Proceedings of the sixteenth ACM symposium on Operating systems principles - SOSP '97. p. 66. doi:10.1145/268998.266660. ISBN 0897919165. ACM SIGOPS Operating Systems Review, v.31 n.5, p. 66–77, Dec. 1997
Houdek, M. E., Soltis, F. G., and Hoffman, R. L. 1981. IBM System/38 support for capability-based addressing. In Proceedings of the 8th ACM International Symposium on Computer Architecture. ACM/IEEE, pp. 341–348.
Intel Corporation (2002) The IA-32 Architecture Software Developer's Manual, Volume 1: Basic Architecture
Levin, R.; Cohen, E.; Corwin, W.; Pollack, F.; Wulf, William (1975). "Policy/mechanism separation in Hydra". ACM Symposium on Operating Systems Principles / Proceedings of the fifth ACM symposium on Operating systems principles. 9 (5): 132–140. doi:10.1145/1067629.806531.
Levy, Henry M. (1984). Capability-based computer systems. Maynard, Mass: Digital Press. ISBN 0-932376-22-3.
Liedtke, Jochen. On µ-Kernel Construction[permanent dead link], Proc. 15th ACM Symposium on Operating System Principles (SOSP), December 1995
Linden, Theodore A. (December 1976). "Operating System Structures to Support Security and Reliable Software". ACM Computing Surveys. 8 (4): 409–445. doi:10.1145/356678.356682. ISSN 0360-0300. , "Operating System Structures to Support Security and Reliable Software" (PDF). Retrieved 2010-06-19.
Lorin, Harold (1981). Operating systems. Boston, Massachusetts: Addison-Wesley. pp. 161–186. ISBN 0-201-14464-6.
Schroeder, Michael D.; Jerome H. Saltzer (March 1972). "A hardware architecture for implementing protection rings". Communications of the ACM. 15 (3): 157–170. doi:10.1145/361268.361275. ISSN 0001-0782.
Shaw, Alan C. (1974). The logical design of Operating systems. Prentice-Hall. p. 304. ISBN 0-13-540112-7.
Tanenbaum, Andrew S. (1979). Structured Computer Organization. Englewood Cliffs, New Jersey: Prentice-Hall. ISBN 0-13-148521-0.
Wulf, W.; E. Cohen; W. Corwin; A. Jones; R. Levin; C. Pierson; F. Pollack (June 1974). "HYDRA: the kernel of a multiprocessor operating system" (PDF). Communications of the ACM. 17 (6): 337–345. doi:10.1145/355616.364017. ISSN 0001-0782.
Baiardi, F.; A. Tomasi; M. Vanneschi (1988). Architettura dei Sistemi di Elaborazione, volume 1 (in Italian). Franco Angeli. ISBN 88-204-2746-X.
Swift, Michael M.; Brian N. Bershad; Henry M. Levy. Improving the reliability of commodity operating systems (PDF).
"Improving the reliability of commodity operating systems". Doi.acm.org. doi:10.1002/spe.4380201404. Retrieved 2010-06-19.
"ACM Transactions on Computer Systems (TOCS), v.23 n.1, p. 77–110, February 2005". Missing or empty |url= (help)
Further reading[edit]
Andrew Tanenbaum, Operating Systems – Design and Implementation (Third edition);
Andrew Tanenbaum, Modern Operating Systems (Second edition);
Daniel P. Bovet, Marco Cesati, The Linux Kernel;
David A. Peterson, Nitin Indurkhya, Patterson, Computer Organization and Design, Morgan Koffman (ISBN 1-55860-428-6);
B.S. Chalk, Computer Organisation and Architecture, Macmillan P.(ISBN 0-333-64551-0).
External links[edit]
Wikiversity has learning resources about Kernel Models at
Operating Systems/Kernel Models
Detailed comparison between most popular operating system kernels
[hide]
v
t
e
Operating systems
General
Advocacy
Comparison
Forensic engineering
History
Hobbyist development
List
Timeline
Usage share
Kernel
Architectures
Exokernel
Hybrid
Microkernel
Monolithic
Rump kernel
Unikernel
Components
Device driver
Loadable kernel module
Microkernel
User space
Process management
Concepts
Context switch
Interrupt
IPC
Process
Process control block
Real-time
Thread
Time-sharing
Scheduling
algorithms
Computer multitasking
Fixed-priority preemptive
Multilevel feedback queue
Preemptive
Round-robin
Shortest job next
Memory management and
resource protection
Bus error
General protection fault
Memory protection
Paging
Protection ring
Segmentation fault
Virtual memory
Storage access and
file systems
Boot loader
Defragmentation
Device file
File attribute
Inode
Journal
Partition
Virtual file system
Virtual tape library
List
AmigaOS
Android
BeOS
BSD
Chrome OS
CP/M
DOS
GNU
Haiku
illumos
IncludeOS
iOS
Linux
Macintosh
Classic Mac OS
macOS
MINIX
MorphOS
MUSIC/SP
Nemesis
NeXTSTEP
NOS
OpenVMS
ORVYL
OS/2
OSv
Pick
QNX
ReactOS
RISC OS
RSTS/E
RSX-11
RT-11
Solaris
TOPS-10/TOPS-20
TPF
Unix
Visi On
VM/CMS
VS/9
webOS
Windows
Xinu
z/OS
Miscellaneous concepts
API
Computer network
HAL
Live CD
Live USB
OS shell
CLI
GUI
TUI
VUI
ZUI
PXE
Authority control
GND: 4338679-9
Retrieved from "https://en.wikipedia.org/w/index.php?title=Kernel_(operating_system)&oldid=838284273"
Categories:
Operating system kernels
Hidden categories:
Webarchive template wayback links
Webarchive template webcite links
All articles with unsourced statements
Articles with unsourced statements from July 2007
Articles with unsourced statements from June 2015
All pages needing factual verification
Wikipedia articles needing factual verification from July 2007
All articles with dead external links
Articles with dead external links from December 2017
Articles with permanently dead external links
CS1 Italian-language sources (it)
Pages using web citations with no URL
Wikipedia articles with GND identifiers
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Article
Talk
Variants
Views
Read
Edit
View history
More
Search
Navigation
Main page
Contents
Featured content
Current events
Random article
Donate to Wikipedia
Wikipedia store
Interaction
Help
About Wikipedia
Community portal
Recent changes
Contact page
Tools
What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Wikidata item
Cite this page
Print/export
Create a book
Download as PDF
Printable version
In other projects
Wikimedia Commons
Languages
Afrikaans
Alemannisch
العربية
অসমীয়া
Asturianu
Azərbaycanca
تۆرکجه
বাংলা
Беларуская
Български
Bosanski
Català
Čeština
Dansk
Deutsch
Eesti
Ελληνικά
Español
Esperanto
Euskara
فارسی
Français
Galego
한국어
हिन्दी
Hrvatski
Ilokano
Bahasa Indonesia
Interlingua
Íslenska
Italiano
עברית
ქართული
Kurdî
ລາວ
Latina
Latviešu
Lietuvių
Lumbaart
Magyar
Македонски
Malagasy
മലയാളം
मराठी
Bahasa Melayu
Монгол
မြန်မာဘာသာ
Nederlands
日本語
Norsk
Norsk nynorsk
ଓଡ଼ିଆ
ਪੰਜਾਬੀ
Polski
Português
Română
Русский
Scots
Sicilianu
සිංහල
Simple English
Slovenčina
Slovenščina
Српски / srpski
Srpskohrvatski / српскохрватски
Suomi
Svenska
Tagalog
ไทย
Türkçe
Українська
Tiếng Việt
中文
64 more
Edit links
This page was last edited on 26 April 2018, at 02:02.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Developers
Cookie statement
Mobile view
Enable previews

key: html

type: local

value: div

attrs: id class

values: mw-page-base noprint

values: mw-head-base noprint

value: a

attrs: id class lang

values: firstHeading firstHeading en

values: siteSub noprint

values: jump-to-nav mw-jump

attrs: href title

attrs: role class

values:
note
hatnote navigation-not-searchable

attrs: href class title

values:
/wiki/Kernel_(disambiguation)
mw-redirect mw-disambig
Kernel (disambiguation)

value: b

value: sup

values: /wiki/Bootloader mw-redirect Bootloader

attrs: alt src width height class srcset data-file-width data-file-height

values:
/wiki/Kernel_space
mw-redirect
Kernel space

values:
/wiki/Resource_(computer_science)
mw-redirect
Resource (computer science)

values:
/wiki/Instruction_set
mw-redirect
Instruction set

values:
/wiki/Virtual_addressing
mw-redirect
Virtual addressing

values:
/wiki/Segmentation_(memory)
mw-redirect
Segmentation (memory)

values:
/wiki/Hardware_bus
mw-redirect
Hardware bus

values:
/wiki/Peripheral_Component_Interconnect
mw-redirect
Peripheral Component Interconnect

values:
/wiki/Universal_Serial_Bus
mw-redirect
Universal Serial Bus

values: This claim needs references to reliable sources. (July 2007)

values:
noprint Inline-Template Template-Fact
white-space:nowrap;

values:
/wiki/Application_Programming_Interface
mw-redirect
Application Programming Interface

values: Edit section: Issues of kernel support for protection

values:
/wiki/Hierarchical_protection_domains
mw-redirect
Hierarchical protection domains

values:
/wiki/Abstraction_level
mw-redirect
Abstraction level

values: Edit section: Hardware-based or language-based protection

values:
/wiki/Edsger_Dijkstra
mw-redirect
Edsger Dijkstra

values:
/wiki/Atomicity_(programming)
mw-redirect
Atomicity (programming)

values: Shared memory (interprocess communication)

values:
/wiki/Brinch_Hansen
mw-redirect
Brinch Hansen

values: Edit section: Kernel-wide design approaches

values:
/wiki/Embedded_systems
mw-redirect
Embedded systems

values:
/wiki/Computer_networking
mw-redirect
Computer networking

values:
/wiki/High-level_language
mw-redirect
High-level language

values: Edit section: Monolithic kernels vs. microkernels

values: This claim needs references to reliable sources. (June 2015)

values:
/wiki/Linux_(kernel)
mw-redirect
Linux (kernel)

values: The material near this tag needs to be fact-checked with the cited source(s). (July 2007)

values: Edit section: Hybrid (or modular) kernels

values:
/wiki/Mach_kernel
mw-redirect
Mach kernel

values:
/wiki/Network_stack
mw-redirect
Network stack

values:
/wiki/Programmable_Interrupt_Controller
mw-redirect
Programmable Interrupt Controller

values:
/wiki/User_Interface
mw-redirect
User Interface

values: Edit section: History of kernel development

values: Edit section: Early operating system kernels

values:
/wiki/Program_loader
mw-redirect
Program loader

values:
/wiki/RC_4000_Multiprogramming_System
mw-redirect
RC 4000 Multiprogramming System

values: Edit section: Time-sharing operating systems

values:
/wiki/Hacker_(computer_security)
mw-redirect
Hacker (computer security)

values:
/wiki/File_management
mw-redirect
File management

values:
/wiki/Lock_(software_engineering)
mw-redirect
Lock (software engineering)

values:
/wiki/Linux_distributions
mw-redirect
Linux distributions

values:
/wiki/Operating_system_development
mw-redirect
Operating system development

values:
/wiki/History_of_Microsoft_Windows
mw-redirect
History of Microsoft Windows

values: Edit section: Development of microkernels

values:
/wiki/Fiasco_(L4_clone)
mw-redirect
Fiasco (L4 clone)

values: Pistachio (L4 clone) (page does not exist)

values:
nofollow
external text
http://www.linfo.org/kernel.html

values:
nofollow
external text
//doi.org/10.1145%2F850697.850701

values:
nofollow
external text
http://www.jya.com/paperF1.htm

values:
nofollow
external text
//doi.org/10.1109%2FPROC.1975.9939

values:
nofollow
external text
//doi.org/10.1145%2F319344.319163

values:
nofollow
http://www.cs.vu.nl/~ast/reliable-os/
external text

values:
nofollow
external text
http://www.multicians.org/fjcc1.html

values:
/wiki/Ring_(computer_security)
mw-redirect
Ring (computer security)

values:
nofollow
external text
http://www.osdever.net

values:
nofollow
external text
http://www.mega-tokyo.com/forum

values:
nofollow
external text
http://www.l4ka.org

values: -moz-column-width: 30em; -webkit-column-width: 30em; column-width: 30em; list-style-type: decimal;

values:
/wiki/Boston,_Massachusetts
mw-redirect
Boston, Massachusetts

values:
/wiki/P._J._Denning
mw-redirect
P. J. Denning

values:
nofollow
external text
//doi.org/10.1145%2F356678.356680

values:
nofollow
external text
//www.worldcat.org/issn/0360-0300

values:
nofollow
external text
//doi.org/10.1145%2F859504.859506

values:
nofollow
external text
//www.worldcat.org/issn/0163-5964

values:
nofollow
external text
//doi.org/10.1145%2F362258.362278

values:
nofollow
external text
//www.worldcat.org/issn/0001-0782

values:
/wiki/Englewood_Cliffs
mw-redirect
Englewood Cliffs

values:
nofollow
external text
//doi.org/10.1145%2F268998.266660

values:
/wiki/Intel_Corporation
mw-redirect
Intel Corporation

values:
nofollow
external text
//doi.org/10.1145%2F1067629.806531

values:
nofollow
external text
//doi.org/10.1145%2F356678.356682

values:
nofollow
external text
//doi.org/10.1145%2F361268.361275

values:
nofollow
external text
//doi.org/10.1145%2F355616.364017

values:
nofollow
external text
//doi.org/10.1002%2Fspe.4380201404

values:
/wiki/Andrew_Tanenbaum
mw-redirect
Andrew Tanenbaum

values: nowraplinks collapsible autocollapse navbox-inner

values:
nofollow
external text
https://d-nb.info/gnd/4338679-9

values: Category:Webarchive template wayback links

values: Category:Webarchive template webcite links

values: Category:All articles with unsourced statements

values: Category:Articles with unsourced statements from July 2007

values: Category:Articles with unsourced statements from June 2015

values: Category:All pages needing factual verification

values: Category:Wikipedia articles needing factual verification from July 2007

values: Category:All articles with dead external links

values: Category:Articles with dead external links from December 2017

values: Category:Articles with permanently dead external links

values: Category:CS1 Italian-language sources (it)

values: Category:Pages using web citations with no URL

values: Category:Wikipedia articles with GND identifiers

values: Discussion about edits from this IP address [ctrl-alt-n]

values: A list of edits made from this IP address [ctrl-alt-y]

values: You are encouraged to create an account and log in; however, it is not mandatory

values: You're encouraged to log in; however, it's not mandatory. [ctrl-alt-o]

values:
/wiki/Kernel_(operating_system)
View the content page [ctrl-alt-c]
c

values: Discussion about the content page [ctrl-alt-t]

values: p-namespaces navigation vectorTabs p-namespaces-label

values:
p-variants
navigation
vectorMenu emptyPortlet
p-variants-label

values: Past revisions of this page [ctrl-alt-h]

values: p-views navigation vectorTabs p-views-label

values:
p-cactions
navigation
vectorMenu emptyPortlet
p-cactions-label

values:
mw-wiki-logo
/wiki/Main_Page
Visit the main page

values:
/wiki/Main_Page
Visit the main page [ctrl-alt-z]
z

values: Featured content – the best of Wikipedia

values: Find background information on current events

values:
/wiki/Special:Random
Load a random article [ctrl-alt-x]
x

values: portal navigation p-navigation p-navigation-label

values: portal navigation p-wikibase-otherprojects p-wikibase-otherprojects-label

values:
interlanguage-link interwiki-af
display: none;

values:
https://als.wikipedia.org/wiki/Kernel
Kernel – Alemannisch
als
als
interlanguage-link-target

values:
interlanguage-link interwiki-als
display: none;

values: نواة (نظم تشغيل) – Arabic

values: কাৰ্ণেল – Assamese

values:
interlanguage-link interwiki-as
display: none;

values:
interlanguage-link interwiki-ast
display: none;

values:
interlanguage-link interwiki-az
display: none;

values: چکیردک(ایشلتیم سیستمی) – South Azerbaijani

values:
interlanguage-link interwiki-azb
display: none;

values: কার্নেল (কম্পিউটার বিজ্ঞান) – Bangla

values:
interlanguage-link interwiki-bn
display: none;

values: Ядро аперацыйнай сістэмы – Belarusian

values:
interlanguage-link interwiki-be
display: none;

values: Ядро (операционна система) – Bulgarian

values:
interlanguage-link interwiki-bg
display: none;

values:
https://bs.wikipedia.org/wiki/Kernel
Kernel – Bosnian
bs
bs
interlanguage-link-target

values:
interlanguage-link interwiki-bs
display: none;

values:
interlanguage-link interwiki-ca
display: none;

values:
interlanguage-link interwiki-cs
display: none;

values:
interlanguage-link interwiki-da
display: none;

values:
interlanguage-link interwiki-de
display: none;

values:
interlanguage-link interwiki-et
display: none;

values: Πυρήνας (υπολογιστές) – Greek

values:
interlanguage-link interwiki-el
display: none;

values:
interlanguage-link interwiki-eo
display: none;

values:
interlanguage-link interwiki-eu
display: none;

values: هسته (رایانش) – Persian

values:
interlanguage-link interwiki-fa
display: none;

values: Noyau de système d'exploitation – French

values:
https://gl.wikipedia.org/wiki/Kernel
Kernel – Galician
gl
gl
interlanguage-link-target

values:
interlanguage-link interwiki-gl
display: none;

values:
interlanguage-link interwiki-ko
display: none;

values: कर्नेल (कम्प्यूटर) – Hindi

values:
interlanguage-link interwiki-hr
display: none;

values:
https://ilo.wikipedia.org/wiki/Kernel
Kernel – Iloko
ilo
ilo
interlanguage-link-target

values:
interlanguage-link interwiki-ilo
display: none;

values:
interlanguage-link interwiki-ia
display: none;

values:
interlanguage-link interwiki-is
display: none;

values:
https://it.wikipedia.org/wiki/Kernel
Kernel – Italian
it
it
interlanguage-link-target

values:
interlanguage-link interwiki-it
display: none;

values: ליבה (מערכות הפעלה) – Hebrew

values:
interlanguage-link interwiki-he
display: none;

values: ოპერაციული სისტემის ბირთვი – Georgian

values:
interlanguage-link interwiki-ka
display: none;

values:
https://ku.wikipedia.org/wiki/Kernel
Kernel – Kurdish
ku
ku
interlanguage-link-target

values:
interlanguage-link interwiki-ku
display: none;

values: ແກນກາງ – Lao

values:
interlanguage-link interwiki-lo
display: none;

values:
interlanguage-link interwiki-la
display: none;

values:
interlanguage-link interwiki-lv
display: none;

values:
interlanguage-link interwiki-lt
display: none;

values:
https://lmo.wikipedia.org/wiki/Kernel
Kernel – Lombard
lmo
lmo
interlanguage-link-target

values:
interlanguage-link interwiki-lmo
display: none;

values:
interlanguage-link interwiki-hu
display: none;

values: Јадро на оперативен систем – Macedonian

values:
interlanguage-link interwiki-mk
display: none;

values:
https://mg.wikipedia.org/wiki/Kernel
Kernel – Malagasy
mg
mg
interlanguage-link-target

values:
interlanguage-link interwiki-mg
display: none;

values: കെർണൽ (കമ്പ്യൂട്ടിങ്) – Malayalam

values:
interlanguage-link interwiki-ml
display: none;

values: केर्नेल – Marathi

values:
interlanguage-link interwiki-mr
display: none;

values: Цөмийн горим – Mongolian

values:
interlanguage-link interwiki-mn
display: none;

values: ကာနဲလ် (ကွန်ပျူတာ) – Burmese

values:
interlanguage-link interwiki-my
display: none;

values:
https://nl.wikipedia.org/wiki/Kernel
Kernel – Dutch
nl
nl
interlanguage-link-target

values:
interlanguage-link interwiki-nl
display: none;

values:
interlanguage-link interwiki-ja
display: none;

values:
interlanguage-link interwiki-no
display: none;

values: Operativsystemkjerne – Norwegian Nynorsk

values:
interlanguage-link interwiki-nn
display: none;

values: କର୍ନେଲ (କମ୍ପ୍ୟୁଟିଙ୍ଗ) – Odia

values:
interlanguage-link interwiki-or
display: none;

values: ਕਰਨਲ (ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ) – Punjabi

values:
interlanguage-link interwiki-pa
display: none;

values:
interlanguage-link interwiki-pl
display: none;

values: Núcleo (sistema operacional) – Portuguese

values:
interlanguage-link interwiki-ro
display: none;

values: Ядро операционной системы – Russian

values:
interlanguage-link interwiki-sco
display: none;

values:
https://scn.wikipedia.org/wiki/Kernel
Kernel – Sicilian
scn
scn
interlanguage-link-target

values:
interlanguage-link interwiki-scn
display: none;

values: කර්නලය (පරිගණක) – Sinhala

values:
interlanguage-link interwiki-si
display: none;

values: Kernel (computer science) – Simple English

values:
interlanguage-link interwiki-simple
display: none;

values:
interlanguage-link interwiki-sk
display: none;

values:
interlanguage-link interwiki-sl
display: none;

values:
interlanguage-link interwiki-sr
display: none;

values:
https://sh.wikipedia.org/wiki/Kernel
Kernel – Serbo-Croatian
sh
sh
interlanguage-link-target

values:
interlanguage-link interwiki-sh
display: none;

values:
interlanguage-link interwiki-fi
display: none;

values:
interlanguage-link interwiki-sv
display: none;

values:
https://tl.wikipedia.org/wiki/Kernel
Kernel – Tagalog
tl
tl
interlanguage-link-target

values:
interlanguage-link interwiki-tl
display: none;

values: เคอร์เนล – Thai

values:
interlanguage-link interwiki-th
display: none;

values:
interlanguage-link interwiki-tr
display: none;

values: Ядро операційної системи – Ukrainian

values:
interlanguage-link interwiki-uk
display: none;

values:
interlanguage-link interwiki-vi
display: none;

values: All languages (initial selection from common choices by you and others)

values: /static/images/wikimedia-button-1.5x.png 1.5x, /static/images/wikimedia-button-2x.png 2x

values: /static/images/poweredby_mediawiki_132x47.png 1.5x, /static/images/poweredby_mediawiki_176x62.png 2x

values:
suggestions
display: none; font-size: 13px;

values: mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Kernel_operating_system rootpage-Kernel_operating_system skin-vector action-view


text:
Diminishing returns
From Wikipedia, the free encyclopedia
Jump to: navigation, search
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (August 2011) (Learn how and when to remove this template message)
Economics
A supply and demand diagram, illustrating
the effects of an increase in demand.
Index
Outline
Category
History
Types
Classification
History of economics
Economic history (academic study)
Schools of economics
Microeconomics
Macroeconomics
Methodology
Heterodox economics
JEL classification codes
Concepts
Theory
Techniques
Econometrics
Economic growth
Economic system
Experimental economics
Mathematical economics
Game theory
Post-scarcity
Market
National accounting
By application
Agricultural
Behavioral
Business
Computational
Cultural
Demographic
Development
Digitization
Ecological
Education
Engineering
Environmental
Evolutionary
Expeditionary
Geography
Health
Industrial organization
Information
International
Knowledge
Labour
Law
Managerial
Monetary / Financial
Natural resource
Organizational
Personnel
Public / Welfare economics
Regional
Rural
Service
Social
Urban
Welfare
Lists
Economists
Publications (journals)
Glossary
Glossary of economics
Business and economics portal
v
t
e
In economics, diminishing returns is the decrease in the marginal (incremental) output of a production process as the amount of a single factor of production is incrementally increased, while the amounts of all other factors of production stay constant.
The law of diminishing returns states that in all productive processes, adding more of one factor of production, while holding all others constant ("ceteris paribus"), will at some point yield lower incremental per-unit returns.[1] The law of diminishing returns does not imply that adding more of a factor will decrease the total production, a condition known as negative returns, though in fact this is common.
A common example is adding more people to a job, such as the assembly of a car on a factory floor. At some point, adding more workers causes problems such as workers getting in each other's way or frequently finding themselves waiting for access to a part. In all of these processes, producing one more unit of output per unit of time will eventually cost increasingly more due to inputs being used less effectively.[2] Another well-studied example is throwing more headcount at software development, yielding Brooks's law.
The law of diminishing returns is a fundamental principle of economics.[1] It plays a central role in production theory.[3]
Contents
[hide]
1 History
2 Diminishing marginal returns
3 Returns and costs
4 See also
5 References
6 Sources
History[edit]
This section needs expansion. You can help by adding to it. (December 2009)
The concept of diminishing returns can be traced back to the concerns of early economists such as Johann Heinrich von Thünen, Jacques Turgot, Adam Smith,[4] James Steuart, Thomas Robert Malthus, and David Ricardo. However, classical economists such as Malthus and Ricardo attributed the successive diminishment of output to the decreasing quality of the inputs. Neoclassical economists assume that each "unit" of labor is identical. Diminishing returns are due to the disruption of the entire productive process as additional units of labor are added to a fixed amount of capital. The law of diminishing returns remains an important consideration in farming.
Diminishing marginal returns[edit]
As labor usage increases from L1 to L2, total output (measured vertically in the top graph) increases by the amount shown. But if labor usage is increased by the same amount again, output goes up by less, implying diminishing marginal returns to the use of labor as an input. The marginal product of labor (measured vertically in the bottom graph) is diminishing everywhere to the right of point A.
This article may lack focus or may be about more than one topic. Please help improve this article, possibly by splitting the article and/or by introducing a disambiguation page, or discuss this issue on the talk page. (September 2011)
The defining feature of diminishing marginal returns is that as total investment increases, the total return on investment as a proportion of the total investment (the average product or return) decreases. Suppose, for example, that 1 kilogram of seed applied to a certain plot of land produces one ton of crop, that 2 kg of seed produces 1.5 tons, and that 3 kg of seed produces 1.75 tons. In formulaic terms, the i {\displaystyle {i}} th kg of seeds produces 1 2 i − 1 {\displaystyle {\frac {1}{2^{i-1}}}} additional tons of crop. The return from investing the first kilogram is 1 t/kg. When 2 kg of seed is invested, the return is 1.5/2 = 0.75 t/kg, and when 3 kg is invested, the return is 1.75/3 = 0.58 t/kg.
In formulaic terms, for this example, the diminished marginal return is:
D = 1 X ∑ i = 1 X 1 2 i − 1 {\displaystyle {\text{D}}={\frac {1}{X}}\sum _{i=1}^{X}{\frac {1}{2^{i-1}}}}
where X {\displaystyle {\text{X}}} = seed in kilograms, and 1 2 i − 1 {\displaystyle {\frac {1}{2^{i-1}}}} = additional crop yield in tons, for the i {\displaystyle {i}} th kilogram of seed.
Substituting 3 for X {\displaystyle {\text{X}}} and expanding yields:
D = 1 3 ∑ i = 1 3 1 2 i − 1 {\displaystyle {\text{D}}={\frac {1}{3}}\sum _{i=1}^{3}{\frac {1}{2^{i-1}}}}
= 1 3 ⋅ ( 1 2 1 − 1 + 1 2 2 − 1 + 1 2 3 − 1 ) {\displaystyle ={\frac {1}{3}}\cdot \left({\frac {1}{2^{1-1}}}+{\frac {1}{2^{2-1}}}+{\frac {1}{2^{3-1}}}\right)}
= 1 3 ⋅ ( 1 2 0 + 1 2 1 + 1 2 2 ) {\displaystyle ={\frac {1}{3}}\cdot \left({\frac {1}{2^{0}}}+{\frac {1}{2^{1}}}+{\frac {1}{2^{2}}}\right)}
= 1 3 ⋅ ( 1 1 + 1 2 + 1 4 ) = 1.75 3 {\displaystyle ={\frac {1}{3}}\cdot \left({\frac {1}{1}}+{\frac {1}{2}}+{\frac {1}{4}}\right)={\frac {1.75}{3}}}
= 0.58 3 ¯ t/kg {\displaystyle =0.58{\overline {3}}{\text{ t/kg}}}
Another example is a factory that has a fixed stock of capital, or tools and machines, and a variable supply of labor. As the firm increases the number of workers, the total output of the firm grows but at an ever-decreasing rate. This is because after a certain point, the factory becomes overcrowded and workers begin to form lines to use the machines. The long-run solution to this problem is to increase the stock of capital, that is, to buy more machines and to build more factories.
Returns and costs[edit]
There is an inverse relationship between returns of inputs and the cost of production. Suppose that a kilogram of seed costs one dollar, and this price does not change. Although there are other costs, assume they do not vary with the amount of output and are therefore fixed costs. One kilogram of seeds yields one ton of crop, so the first ton of the crop costs one dollar to produce. That is, for the first ton of output, the marginal cost of the output is $1 per ton. If there are no other changes, then if the second kilogram of seeds applied to land produces only half the output of the first, the marginal cost would equal $1 per half ton of output, or $2 per ton. Similarly, if the third kilogram of seeds yields only a quarter ton, then the marginal cost equals $1 per quarter ton or $4 per ton. Thus, diminishing marginal returns imply increasing marginal costs and rising average costs.
Cost can also be measured in terms of opportunity cost. In this case the law also applies to societies – the opportunity cost of producing a single unit of a good generally increases as a society attempts to produce more of that good. This explains the bowed-out shape of the production possibilities frontier.
See also[edit]
Economics portal
Diminishing marginal utility, also not to be mistaken for 'diminishing returns'
Diseconomies of scale, does not assume fixed inputs, thus differing from 'diminishing returns'
Economies of scale
Increasing returns
Learning curve and Experience curve effects
Liebig's Law of the minimum
Marginal value theorem
Opportunity cost
Pareto principle
Submodular set function
Tendency of the rate of profit to fall
References[edit]
^ Jump up to: a b Samuelson, Paul A.; Nordhaus, William D. (2001). Microeconomics (17th ed.). McGraw-Hill. p. 110. ISBN 0071180664.
Jump up ^ George, Henry. The Science of Political Economy. New York: Robert Schalkenbach Foundation.
Jump up ^ Encyclopædia Britannica. Encyclopædia Britannica, Inc. 26 Jan 2013. ISBN 9781593392925.
Jump up ^ Smith, Adam. The wealth of nations. Thrifty books. ISBN 9780786514854.
Sources[edit]
Case, Karl E.; Fair, Ray C. (1999). Principles of Economics (5th ed.). Prentice-Hall. ISBN 0-13-961905-4.
[show]
v
t
e
Economics
Economic theory
Econometrics
Applied economics
Macroeconomics
Adaptive expectations
Aggregate demand
Balance of payments
Business cycle
Capacity utilization
Capital flight
Central bank
Consumer confidence
Currency
Demand shock
Depression (Great Depression)
DSGE
Economic growth
Economic indicator
Economic rent
Effective demand
General Theory of Keynes
Hyperinflation
Inflation
Interest
Interest rate
Investment
IS–LM model
Microfoundations
Monetary policy
Money
NAIRU
National accounts
PPP
Rate of profit
Rational expectations
Recession
Saving
Shrinkflation
Stagflation
Supply shock
Unemployment
Macroeconomics publications
Microeconomics
Aggregation problem
Budget set
Consumer choice
Convexity
Cost–benefit analysis
Deadweight loss
Distribution
Duopoly
Economic equilibrium
Economic shortage
Economic surplus
Economies of scale
Economies of scope
Elasticity
Expected utility hypothesis
Externality
General equilibrium theory
Indifference curve
Intertemporal choice
Marginal cost
Market failure
Market structure
Monopoly
Monopsony
Non-convexity
Oligopoly
Opportunity cost
Preference
Production set
Profit
Public good
Returns to scale
Risk aversion
Scarcity
Social choice theory
Sunk costs
Supply and demand
Theory of the firm
Trade
Transaction cost
Value
Uncertainty
Utility
Microeconomics publications
Applied fields
Agricultural
Business
Demographic
Development
Economic history
Education
Engineering
Environmental
Financial
Health
Industrial organization
International
Knowledge
Labour
Law and economics
Monetary
Natural resource
Public
Service
Transportation
Urban
Welfare
Methodology
Behavioral economics
Computational economics
Econometrics
Economic systems
Experimental economics
Mathematical economics
Methodological publications
Economic thought
Ancient economic thought
Austrian school of economics
Chicago school of economics
Classical economics
Feminist economics
Heterodox economics
Institutional economics
Keynesian economics
Mainstream economics
Marxian economics
Neoclassical economics
Post-Keynesian economics
Schools overview
Notable economists and
thinkers within economics
Kenneth Arrow
Gary Becker
Francis Ysidro Edgeworth
Milton Friedman
Ragnar Frisch
Friedrich Hayek
Harold Hotelling
John Maynard Keynes
Tjalling Koopmans
Paul Krugman
Robert Lucas Jr.
Jacob Marschak
Alfred Marshall
Karl Marx
John von Neumann
Vilfredo Pareto
David Ricardo
Paul Samuelson
Joseph Schumpeter
Amartya Sen
Herbert A. Simon
Adam Smith
Robert Solow
Léon Walras
more
International organizations
Asia-Pacific Economic Cooperation
Economic Cooperation Organization
European Free Trade Association
International Monetary Fund
Organisation for Economic Co-operation and Development
World Bank
World Trade Organization
Category
Index
Lists
Outline
Publications
Business and economics portal
Retrieved from "https://en.wikipedia.org/w/index.php?title=Diminishing_returns&oldid=804419118"
Categories:
Economics laws
Production economics
Hidden categories:
Articles needing additional references from August 2011
All articles needing additional references
Articles to be expanded from December 2009
All articles to be expanded
Articles using small message boxes
Wikipedia articles lacking focus from September 2011
All Wikipedia articles lacking focus
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Article
Talk
Variants
Views
Read
Edit
View history
More
Search
Navigation
Main page
Contents
Featured content
Current events
Random article
Donate to Wikipedia
Wikipedia store
Interaction
Help
About Wikipedia
Community portal
Recent changes
Contact page
Tools
What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Wikidata item
Cite this page
Print/export
Create a book
Download as PDF
Printable version
Languages
Alemannisch
العربية
Català
Čeština
Deutsch
Español
Euskara
فارسی
Français
한국어
हिन्दी
Íslenska
Italiano
עברית
日本語
Polski
Português
Русский
Slovenčina
Suomi
Svenska
Українська
Tiếng Việt
中文
Edit links
This page was last edited on 8 October 2017, at 21:57.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Developers
Cookie statement
Mobile view
Enable previews

values: mw-page-base noprint

values: mw-head-base noprint

values: firstHeading firstHeading en

values: siteSub noprint

values: jump-to-nav mw-jump

value: img

attrs: alt src width height srcset data-file-width data-file-height

attrs: href class

value: td

attrs: class href

values: Help:Introduction to referencing with Wiki Markup/1

value: span

value: i

value: small

value: tr

values: plainlinks metadata ambox ambox-content ambox-Refimprove

values: padding:0.2em 0.4em 0.2em;font-size:145%;line-height:1.2em;background: none;

values: padding:0.3em 0.4em 0.3em;font-weight:bold;padding:0.15em 0.15em 0.25em; display:block; margin-bottom:0.55em; background-color: #efefef;

values: padding:0 0.1em 0.4em;padding:0.15em 0.25em 0.5em;

values: List of important publications in economics

values: padding:0.3em 0.4em 0.3em;font-weight:bold;background-color: #efefef;

values: float:right;clear:right;width:22.0em;margin:0 0 1.0em 1.0em;background:#f9f9f9;border:1px solid #aaa;padding:0.2em;border-spacing:0.4em 0;text-align:center;line-height:1.4em;font-size:88%

values:
/wiki/Production_theory_basics
mw-redirect
Production theory basics

values: plainlinks metadata ambox mbox-small-left ambox-content

values: Anne-Robert-Jacques Turgot, Baron de Laune

values: Edit section: Diminishing marginal returns

values:
plainlinks metadata ambox ambox-content
presentation

values: vertical-align: -0.338ex; width:0.802ex; height:2.176ex;

values: vertical-align: -2.338ex; width:4.899ex; height:5.676ex;

values: vertical-align: -3.005ex; width:16.718ex; height:7.343ex;

values: vertical-align: -0.338ex; width:1.743ex; height:2.176ex;

values: vertical-align: -3.005ex; width:15.901ex; height:7.176ex;

values: vertical-align: -2.505ex; width:30.693ex; height:6.176ex;

values: vertical-align: -2.505ex; width:24.391ex; height:6.176ex;

values: vertical-align: -2.505ex; width:29.298ex; height:6.176ex;

values: vertical-align: -0.838ex; width:12.903ex; height:3.343ex;

values:
/wiki/Production_possibilities_frontier
mw-redirect
Production possibilities frontier

values: display:table-cell;padding:0.2em 0.2em 0.2em 0.3em;vertical-align:middle

values: margin:0.5em 0 0.5em 1em;border:solid #aaa 1px

values:
/wiki/Increasing_returns
mw-redirect
Increasing returns

values:
/wiki/Liebig%27s_Law_of_the_minimum
mw-redirect
Liebig's Law of the minimum

values:
reflist mw-references-wrap
list-style-type: decimal;

values:
/wiki/Economic_theory
mw-redirect
Economic theory

values: The General Theory of Employment, Interest and Money

values:
/wiki/Austrian_school_of_economics
mw-redirect
Austrian school of economics

values: nowraplinks hlist collapsible collapsed navbox-inner

values: Category:Articles needing additional references from August 2011

values: Category:All articles needing additional references

values: Category:Articles to be expanded from December 2009

values: Category:Articles using small message boxes

values: Category:Wikipedia articles lacking focus from September 2011

values: Category:All Wikipedia articles lacking focus

values: Discussion about edits from this IP address [ctrl-alt-n]

values: A list of edits made from this IP address [ctrl-alt-y]

values: You are encouraged to create an account and log in; however, it is not mandatory

values: You're encouraged to log in; however, it's not mandatory. [ctrl-alt-o]

values:
/wiki/Diminishing_returns
View the content page [ctrl-alt-c]
c

values: Discussion about the content page [ctrl-alt-t]

values: p-namespaces navigation vectorTabs p-namespaces-label

values:
p-variants
navigation
vectorMenu emptyPortlet
p-variants-label

values: Past revisions of this page [ctrl-alt-h]

values: p-views navigation vectorTabs p-views-label

values:
p-cactions
navigation
vectorMenu emptyPortlet
p-cactions-label

values:
mw-wiki-logo
/wiki/Main_Page
Visit the main page

values:
/wiki/Main_Page
Visit the main page [ctrl-alt-z]
z

values: Featured content – the best of Wikipedia

values: Find background information on current events

values:
/wiki/Special:Random
Load a random article [ctrl-alt-x]
x

values: portal navigation p-navigation p-navigation-label

values: Guidance on how to use and edit Wikipedia

values: About the project, what you can do, where to find things

values: A list of recent changes in the wiki [ctrl-alt-r]

values: portal navigation p-interaction p-interaction-label

values: List of all English Wikipedia pages containing links to this page [ctrl-alt-j]

values: Recent changes in pages linked from this page [ctrl-alt-k]

values:
/wiki/Wikipedia:File_Upload_Wizard
Upload files [ctrl-alt-u]
u

values: A list of all special pages [ctrl-alt-q]

values: Permanent link to this revision of the page

values: Link to connected data repository item [ctrl-alt-g]

values: Printable version of this page [ctrl-alt-p]

values: Gesetz vom abnehmenden Grenzertrag – Alemannisch

values: قانون الإنتاجية المتناقصة – Arabic

values: Llei de rendiments decreixents – Catalan

values: interlanguage-link interwiki-cs badge-Q17437798 badge-goodarticle

values: Ley de los rendimientos decrecientes – Spanish

values: بازده نزولی – Persian

values: Loi des rendements décroissants – French

values: ह्रासमान प्रतिफल – Hindi

values: Lögmál um minnkandi afrakstur – Icelandic

values: תפוקה שולית פוחתת – Hebrew

values: Lei dos rendimentos decrescentes – Portuguese

values: Закон убывающей доходности – Russian

values: Закони спадної віддачі – Ukrainian

values: Quy luật hiệu suất giảm dần – Vietnamese

values: mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Diminishing_returns rootpage-Diminishing_returns skin-vector action-view