| commit | ddb0ea5eb2609f7a6504bd919b991b2de371b96b | [log] [tgz] |
|---|---|---|
| author | David Stevens <stevensd@google.com> | Thu Dec 13 14:39:12 2018 -0800 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Jan 31 05:50:21 2019 +0000 |
| tree | bd8977297bc81d3d6a383f83655b18131be87dd8 | |
| parent | cfbad33e836df46e31c3b8c0759db644541e418e [diff] |
[kernel][vm] Implement commit on pager vmos Committing a pager vmo generates page requests to the backing pager service. The kernel will attempt to batch requests for adjacent pages, but the pager API makes no guarantees about exactly what the batching behavior is. For a single commit operation, the current implementation generates a single batched page request for each run of non-resident pages which do not already have outstanding page requests. For a commit operation which is broken up into multiple requests, the requests are dispatched serially, in the sense that the next request will not be dispatched until the current request is fully supplied. This implementation uses a missing page count to track how much work is left for a pending page request. This can result in redundant page requests if pages are removed from under a pending page request. Given that it greatly simplifies request tracking and that redundant requests are not technically a pager API violation, it seems like a worthwhile trade-off. Furthermore, this should be rare in the current system, and may become impossible if decommit becomes less forceful (and evict handles it). The commit-centric pager tests in core-tests do test the batching behavior of the kernel, as the correctness of such behavior is important for the efficiency of the system. However, that does not mean that the behavior is part of the pager API's contract. Test: /boot/test/core/pager-test Test: Pave, boot, use session shell on nuc Test: vmstress from sandbox/stevensd/userpager for 48+ hours on nuc/vim Test: repeatedly run and kill vmstress for 12+ hours on nuc ZX-1480 #comment [kernel][vm] Implement commit on pager vmos Change-Id: I65b594a9f3957f2d1e94086852fb3e322847afcd
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.