Fast boot
摘要
說明書
In various embodiments, the use of synchronization mechanisms like locks is minimal. Locks are used, for example, to insert queue and remove queue continuations on scheduler objects and to maintain the event table.
Code Path Lengths
In some embodiments, the (maximum) length of all code paths is determined through a static code analysis, resulting in estimable and bounded amounts of time spent in the hyper-kernel itself. All data structures can be pre-allocated, for example, as indexed arrays. The nodes of the TidalTree are determined at boot time and are invariant, as are the number of steps in their traversal. One variable length computation has to do with the length of the work queues, but even that can be bounded, and a worst-case estimate computed. In other embodiments, other variable length computations are used.
Static Storage
In various embodiments, all data structures needed in the hyper-kernel are static, and determined at boot time, so there is no need for dynamic memory allocation or garbage collection.
Physical Memory
All memory used by the hyper-kernel is physical memory, so no page tables or virtual memory is required for its internal operations (except, e.g., to manage the virtual resources it is managing), further helping the hyper-kernel to co-exist with an operating system.
Sharing Data and Maintaining Consistency
