Content deleted Content added
→Library: Small grammatical correction and noted the potential to inline library calls |
→Library: Added note about context switch overhead being not negligible, supported by a reference |
||
Line 39:
===Library===
A ''library operating system'' (libOS) is one in which the services that a typical operating system provides, such as networking, are provided in the form of [[Library (computing)|libraries]] and composed with a single application and configuration code to construct a [[unikernel]]:
<ref name="Unikernels">{{cite magazine |last1=Madhavapeddy |first1=Anil
|last2=Scott |first2=David J
Line 51 ⟶ 52:
|url=https://doi.org/10.1145/2557963.2566628
|doi=10.1145/2557963.2566628
|access-date=2024-08-07
}}</ref> a specialized (only the absolute necessary pieces of code are extracted from libraries and bound together <ref name="Unikraft-Build-Process">{{cite web |url=https://unikraft.org/docs/concepts/build-process
|access-date=2024-08-08
Line 57 ⟶ 60:
|archive-date=2024-04-22
|archive-url=https://web.archive.org/web/20240422183734/https://unikraft.org/docs/concepts/build-process
|url-status=live
}}</ref>), [[Single address space operating system|single address space]], machine image that can be deployed to cloud or embedded environments. The operating system code and application code are not executed in separated [[Protection ring|protection domains]] (there is only a single application running, at least conceptually, so there is no need to prevent interference between applications) and OS services are accessed via simple library calls (potentially [[Inline expansion|inlining]] them based on compiler thresholds), without the usual overhead of [[Context switch|context switches]],
<ref name="rise-of-libOS">{{cite web |url=https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/
|access-date=2024-08-07
Line 67 ⟶ 72:
|archive-date=2024-03-01
|archive-url=https://web.archive.org/web/20240301072916/https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/
|url-status=live
}}</ref> in a way similarly to embedded and real-time OSes. Note that this overhead is not negligible: to the direct cost of mode switching it's necessary to add the indirect pollution of important processor structures (like [[CPU cache]]s, the [[Instruction pipelining|instruction pipeline]], and so on) which affects both user-mode and kernel-mode performance.
<ref name="FlexSC">{{cite conference
|url=https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls
|title=FlexSC: Flexible System Call Scheduling with Exception-Less System Calls
|last1=Soares |first1=Livio Baldini <!-- https://liviosoares.github.io/ -->
|last2=Stumm |first2=Michael <!-- https://www.eecg.toronto.edu/~stumm/index.html -->
|date=2010-10-04
|conference=OSDI '10, 9th USENIX Symposium on Operating System Design and Implementation
|conference-url=https://www.usenix.org/legacy/events/osdi10/
|publisher=[[USENIX]]
|access-date=2024-08-09
|quote=Synchronous implementation of system calls negatively impacts the performance of system intensive workloads, both in terms of the ''direct'' costs of mode switching and, more interestingly, in terms of the ''indirect'' pollution of important processor structures which affects both user-mode and kernel-mode performance. A motivating example that quantifies the impact of system call pollution on application performance can be seen in Figure 1. It depicts the user-mode instructions per cycles (kernel cycles and instructions are ignored) of one of the SPEC CPU 2006 benchmarks (Xalan) immediately before and after a <code>pwrite</code> system call. There is a significant drop in instructions per cycle (IPC) due to the system call, and it takes up to 14,000 cycles of execution before the IPC of this application returns to its previous level. As we will show, this performance degradation is mainly due to interference caused by the kernel on key processor structures.
|quote-page=2
}}</ref>
==History==
| |||