SPECK内核：可扩展预测性的核心设计

61 浏览量更新于2024-08-25 收藏 268KB PDF 举报

"SPECK - A Kernel for Scalable Predictability (rtas15speck)-计算机科学" 在当今的计算机科学领域，多核和多线程系统已经广泛应用于嵌入式系统中。随着技术的发展，这些系统对于隔离不同分区和处理不同关键性的需求日益增长。然而，现有的软件系统在应对这种复杂情况时往往力不从心。关键问题在于如何在并发环境中保证共享数据结构的一致性，通常依赖于锁机制，这些机制依赖于可预测的资源共享协议。但随着核心数量的增加，单个共享缓存行（如锁）可能会引发显著的干扰，这给系统的性能和可预测性带来了挑战。 "SPECK: a Kernel for Scalable Predictability" 是由Qi Wang、Yuxin Ren、Matt Scaperoth和Gabriel Parmer共同提出的解决方案，他们来自乔治华盛顿大学。论文的摘要指出，SPECK内核是COMPOSITE操作系统的新一代设计，其目标是提供一种可扩展的预测性模型。在这种模型中，当核心数量增加时，单个核心上的预测性边界保持不变，这意味着系统的可预测性不会因核心数量的增加而显著降低。该研究强调了非抢占式内核在实现强可扩展预测性方面的能力，尽管非抢占式内核通常被认为在调度灵活性上存在限制，但SPECK内核通过优化资源管理策略，成功地降低了平均情况下的运行开销，并且在保持系统稳定性的同时，避免了传统系统中由于核心增加而导致的性能下降问题。 SPECK内核的设计考虑了以下几个关键点： 1. **资源隔离与预测性**：为了减少核心间的干扰，SPECK可能采用了更精细的资源分配和管理策略，确保每个核心对共享资源的访问具有可预测性。 2. **一致性协议**：SPECK可能采用了创新的一致性协议，以减少锁带来的延迟和不确定性，确保多核心环境下数据一致性。 3. **调度策略**：尽管是非抢占式内核，但SPECK可能采用了智能调度算法，能够在不打断任务执行的情况下，有效地平衡负载和优先级，从而保持系统的整体效率。 4. **性能优化**：为了降低平均情况下的运行开销，SPECK可能引入了针对多核环境的优化技术，比如硬件辅助的同步原语或者高效的缓存一致性机制。 5. **可扩展性**：SPECK内核的设计目标是保持性能预测性在增加核心时的稳定性，这意味着其架构应该是模块化和可扩展的，以适应未来更复杂的多核系统。 SPECK内核的提出是为了应对多核系统中的预测性和一致性问题，通过重新设计内核架构和优化算法，它在保持系统性能的同时，实现了可扩展的预测性，为嵌入式系统和高要求的实时应用提供了新的可能性。

be limited by any kernel contention, particularly from lower-

criticality interference. We seek a particularly strict sense of

scalability: even in the worst-case the latency bounds made

on a single core should hold with increases in core count.

G1 Avoid cache-line contention for real-time tasks. Given

the overheads of modifying a shared cache-line, SPECK is

designed to (1) ensure objects ﬁt into a single cache-line and

provide synchronization at that ﬁnest-possible granularity of

contention, (2) ensure that all contention is explicit to user-

level through the system-call API so that it can be avoided, and

(3) ensure that the common-case uses of the kernel perform no

shared cache-line modiﬁcations. One key to avoiding cache-

line modiﬁcations in the common case is to provide liveness

tracking of kernel objects. The key question of “when can an

object be deallocated?” is complicated by parallel accesses to

it, and common solutions such as reference counting do not

scale.

G2 User-level deﬁnition of policy, and pervasive inter-

component isolation. A fundamental goal of COMPOSITE

is the extraction of resource management policy from the

kernel to user-level components. SPECK takes this one step

further, and enables the component-based control over all

kernel scalability properties. This is essential to provide strong

temporal isolation boundaries between components to match

the spatial isolation provided by hardware protection.

G3 Aggressive optimization of the fast-paths. Optimizing for

scalability often implies slowing and complicating the code.

For example, ﬁne-grained locking increases parallelism, but

imposes more overhead [6]. SPECK is intended to not only

provide latencies that do not increase with an increasing core

count, but with latencies that are competitive on a single core

with existing state-of-the-art systems.

IV. DESIGN AND IMPLEMENTATION OF SPECK

SPECK leverages a clean-slate co-design of the ker-

nel’s data-structures, interface, and contention mechanisms

to achieve the required scalable predictability guarantees.

This co-design enables the ﬁnest-gained synchronization at

the level of individual kernel-object cache-lines, an explicit

interface mapping from the kernel namespace to cache-lines

that enables explicit cache-line contention avoidance, and

a quiescence-based reclamation scheme based on the very

predictability guarantees made by the kernel.

SPECK also maintains the ﬁne-grained component-based

isolation of COMPOSITE systems, and the implementation

of all resource management policy in user-level components.

Components here refer to a unit of code of data that 1) are

memory isolated and execute in user-level, 2) export a set

of functions that can be invoked by other components, and

3) have a set of functional dependencies on other components.

A system is composed from a collection of speciﬁcally chosen

components by satisfying all of their functional dependencies.

Components in COMPOSITE include application processes

and middle-ware in addition to low-level policies such as

schedulers, memory managers, synchronization managers, ﬁle

systems, and networking protocols.

A. SPECK Kernel Abstractions

SPECK has a small number of abstractions. These are

focused around providing 1) the access control necessary to

strictly control both the system resources accessible by each

component, and the modiﬁcation permissions to each of those

resources to limit cache coherency operations, 2) efﬁcient

and bounded-latency access to those resources, and 3) the

capability to deﬁne system resource management policies in

user-level components.

Fig. 1: SPECK’s main data-structures. Components (here, a client

, and a manager, C

) each include a KOTBL and PGTBL. C

has a SINV object in a KOTBL slot (labeled S), that enables it to

invoke C

. In this case, C

provides a memory mapping service, so

slots (labeled H) in its KOTBL include higher-order PGTBLs. Thus,

can modify the PGTBL of the client by adding pages into it.

A kernel thread structure includes an invocation stack that tracks a

thread’s execution as it migrates between components. In this case,

the thread has invoked C

from C

(the stack grows down). System

memory is referenced within the PGTBLs.

Resource tables (RESTBLs). Each component is deﬁned by a

set of resource tables that index and control access to system

resources. Each resource table is a radix trie consisting of

nodes up to a ﬁxed depth. Each node in the radix trie has a

number of slots that hold references to other kernel objects.

Slots in nodes that are internal in the radix trie (i.e. non-leaf

nodes) hold references to nodes of the next level. Each radix

trie maps an index into a slot in a leaf node that references

a resource (e.g. a thread, memory frame, and other resource

tables). This same data-structure is used for various system

structures, each with different internal node radices, different

numbers of slots in the leaves, and different node sizes. These

include:

• KOTBL – the Kernel Object tables enable components to

access and use kernel objects. The only system call in SPECK

performs an operation on the kernel object at an index in the

KOTBL.

• PGTBL – page-tables are the main mechanism for tracking

not only virtual mappings for the component, but also access

to physical memory used for kernel data-structures.

• LIVENESS TABLE – This structure is used to track the

liveness and quiescence of kernel objects. This structure will

be elaborated in Section IV-F.

The only mechanism to make modiﬁcations to resource

tables is higher-order resource tables – references within

resource tables to resource tables, themselves. Most compo-

nents in the system do not have such access, thus make no

modiﬁcations to shared kernel structures. Components with

access to higher order resource tables are in charge of handling

delegation of, and access to, resources throughout the system.

剩余11页未读，继续阅读

weixin_38608189

粉丝: 4
资源: 922

SPECK内核：可扩展预测性的核心设计

node-speck-sensor:用于CMU CREATE Lab Speck粒子传感器的Node.js接口

Speck-Chrome-App:CreateLab Speck 的 Chrome 应用程序

实现Speck分组密码算法

SPECK 算法程序

AES和Speck分组密码算法性能和实现上的不同之处。

AES和Speck加密算法中对性能影响最大的子模块（函数）是哪个？

Spring Boot 评论系统.zip

基于thinkPHP6+的站长必备工具箱最新在线工具箱网站系统源码分享下载

springboot基于Android的饮食健康管理系统毕业论文.docx

基于java的地方美食分享网站设计与实现.docx

最新资源