CN109923523B - 计算机系统及用于计算机系统的方法 - Google Patents

计算机系统及用于计算机系统的方法 Download PDF

Info

Publication number
CN109923523B
CN109923523B CN201780065872.8A CN201780065872A CN109923523B CN 109923523 B CN109923523 B CN 109923523B CN 201780065872 A CN201780065872 A CN 201780065872A CN 109923523 B CN109923523 B CN 109923523B
Authority
CN
China
Prior art keywords
thread
node
page
vcpu
guest
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201780065872.8A
Other languages
English (en)
Other versions
CN109923523A (zh
Inventor
I.R.纳西
K.约安尼多
D.P.里德
方宜群
M.伯曼
M.希尔
B.莫菲特
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Priority to CN202310380629.2A priority Critical patent/CN116401058A/zh
Priority to CN202310380092.XA priority patent/CN116401057A/zh
Publication of CN109923523A publication Critical patent/CN109923523A/zh
Application granted granted Critical
Publication of CN109923523B publication Critical patent/CN109923523B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/3009—Thread control instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G06F9/30123—Organisation of register space, e.g. banked or distributed register file according to context, e.g. thread buffers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
    • G06F9/3856—Reordering of instructions, e.g. using queues or age tags
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G06F9/4862—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration the task being a mobile agent, i.e. specifically designed to migrate
    • G06F9/4875—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration the task being a mobile agent, i.e. specifically designed to migrate with migration policy, e.g. auction, contract negotiation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing

Abstract

公开了将工作集与线程相关联。接收停顿事件的指示。响应于接收到停顿事件的指示，保存与该停顿事件相关联的处理器的状态。从保存的处理器状态获得在处理器中运行的客户线程的标识符和由处理器引用的客户物理地址中的至少一个。

Description

计算机系统及用于计算机系统的方法
其他申请的交叉引用
本申请要求于2017年2月10日提交的题为ASSOCIATING WORKING SETS ANDTHREADS的美国临时专利申请No.62/457,609、2016年8月29日提交的题为DYNAMICSCHEDULING的美国临时专利申请No.62/380,896、2017年3月8日提交的题为DYNAMICSCHEDULING的美国临时专利申请No.62/468,856、2017年6月27日提交的题为RESOURCEMIGRATION NEGOTIATION的美国临时专利申请No.62/525,544，以及2017年6月27日提交的题为MEMORY THREAD LOCALITY的美国临时专利申请No.62/525,552的优先权，全部这些美国临时专利申请都出于全部目的通过引用结合于本文。
技术领域
本公开总体上涉及计算机系统技术领域。
背景技术
软件应用越来越多地在大型数据集上运行，并且它们本身变得越来越复杂。在一些情况下，分布式计算系统被用来支持这样的应用(例如，这里大型数据库系统将数据的部分分布到不同服务器节点的景观(landscape)上，并且将查询优化为得以在该景观上分布的子查询)。遗憾的是，在数据放置和数据访问分布方法(包括联网的复杂性)方面，必须花费大量努力来管理该分布。如果景观发生变化、如果数据组织发生变化、或者如果工作负载发生变化，则将需要大量工作。更一般地，复杂计算系统的行为随时间而变化，例如，随着新发布的应用、添加新的中间软件层、新的操作系统版本、新的处理器模型、改变的数据的结构特性、增加的数据量以及不同的数据访问模式。
发明内容
根据本公开的一个方面，提供了一种计算机系统，包括：多个互连的计算节点，其中，每个计算节点包括多个物理处理器；其中，响应于接收到与运行在物理处理器上的虚拟处理器相关联的停顿事件的指示，确定在虚拟处理器中运行的客户线程的标识符和由在虚拟处理器中运行的客户线程引用的客户物理地址；其中，由客户线程引用的客户物理地址由客户线程记录在页面访问的历史中；以及其中，至少部分地基于页面访问的历史中所包括的信息，通过将虚拟处理器迁移到由客户物理地址标识的物理存储器的页面在其上的节点来至少部分地处理停顿事件，其中所述停顿事件与非本地页面的访问相关联。
根据本公开的另一方面，提供了一种用于计算机系统的方法，其包括：响应于接收到与虚拟处理器相关联的停顿事件的指示，确定在虚拟处理器中运行的客户线程的标识符和由在虚拟处理器中运行的客户线程引用的客户物理地址，其中，虚拟处理器运行在物理处理器上，物理处理器被包括在多个互连的计算节点中，其中，每个计算节点包括多个物理处理器；将由客户线程引用的客户物理地址由客户线程记录在页面访问的历史中；以及至少部分地基于页面访问的历史中所包括的信息，通过将虚拟处理器迁移到由客户物理地址标识的物理存储器的页面在其上的节点来至少部分地处理停顿事件，其中所述停顿事件与非本地页面的访问相关联。
附图说明
在以下详细描述和附图中公开了本发明的各种实施例。
在以下详细描述和附图中公开了本发明的各种实施例。
图1图示了计算机系统的实施例。
图2将计算机系统的物理结构图示为层次结构。
图3A描绘了其中多个虚拟机(具有相应的多个客户操作系统)在单个物理机器上运行的虚拟化计算环境。
图3B描绘了其中多个物理机器共同地运行单个虚拟操作系统的虚拟化计算环境。
图4A描绘了软件栈的示例。
图4B描绘了软件栈的示例。
图5描绘了示例系统上的硬件的操作系统的视图的示例。
图6A描绘了单个节点上的硬件的超线程的视图的示例。
图6B描绘了示例系统上的硬件的超内核的视图的示例。
图7描绘了企业超级计算机系统的示例上的硬件的操作系统的视图的示例。
图8图示了用于选择性地迁移资源的过程的实施例。
图9图示了用于实行分层动态调度的过程的实施例。
图10图示了初始存储器指派和处理器指派的示例。
图11图示了存储器指派的更新视图和处理器指派的无变化视图。
图12图示了存储器指派和处理器指派的更新视图。
图13A是其中线程和工作集相关联的环境的示例实施例。
图13B图示了虚拟化环境中的动态地址转换的示例。
图13C图示了实行第二级地址转换的示例实施例。
图13D图示了被用来存储关于客户线程的信息的表格的示例实施例。
图13E是图示了用于关联工作集和线程的过程的实施例的流程图。
图14A图示了客户虚拟机的示例初始配置。
图14B图示了用于请求页面的事务的示例第一阶段。
图14C图示了用于请求页面的事务的示例第二阶段。
图14D图示了用于请求页面的事务的示例第三阶段。
图14E图示了用于请求页面的事务的示例最终结果。
图14F是图示了用于资源迁移协商的过程的实施例的流程图。
图15A图示了TidalTree的示例实施例。
图15B是图示了搜索在其上入列(enqueue)准备运行的vcpu的pcpu队列的实施例的示图。
图15C是图示了用于处理停顿(stall)事件的过程的实施例的流程图。
图15D是图示了用于搜索准备运行的vcpu的过程的实施例的流程图。
图15E是图示了用于在TidalTree上放置准备运行的vcpu的过程的实施例的流程图。
具体实施方式
本发明可以用众多方式实现，该方式包括：作为过程；装置；系统；物质的组成；体现在计算机可读存储介质上的计算机程序产品；和/或处理器，诸如被配置成执行存储在耦合到处理器的存储器上和/或由耦合到处理器的存储器提供的指令的处理器。在本说明书中，这些实现方式或者本发明可以采用的任何其它形式可以被称为技术。一般而言，可以在本发明的范围内改变所公开过程的步骤的次序。除非另行说明，否则可以将被描述为被配置成实行任务的诸如处理器或存储器之类的组件实现为被暂时配置成在给定时间实行任务的通用组件，或被制造成实行该任务的专用组件。如本文中使用的，术语“处理器”指代被配置成处理数据(诸如计算机程序指令)的一个或多个设备、电路和/或处理核心。
下面连同图示了本发明的原理的附图来提供对本发明的一个或多个实施例的详细描述。结合这样的实施例对本发明进行描述，但是本发明并不限于任何实施例。本发明的范围仅受权利要求限制，并且本发明涵盖众多替换方案、修改和等同物。在以下描述中阐述了众多具体细节，以便提供对本发明的透彻理解。出于示例的目的来提供这些细节，并且可以根据权利要求在没有这些具体细节中的一些或全部的情况下实践本发明。出于清晰的目的，在与本发明相关的技术领域中已知的技术材料并未被详细描述，以使得不会不必要地模糊本发明。
图1图示了计算机系统的实施例。系统100在本文中也被称为“企业超级计算机”和“大型机”。在所示的示例中，系统100包括很靠近地定位的(例如，位于同一机架内)多个节点(例如，节点102-108)。在其他实施例中，可在系统中使用节点的多个机架(例如，位于同一设施内)。另外，也可与分布式系统相结合地使用本文中所描述的技术。
节点用诸如10吉比特以太网、直接PCI到PCI和/或无限带宽技术(InfiniBand)之类的高速互连(110)来互连。每个节点包括商品服务器类硬件组件(例如，机架中具有其附连或包含的外围设备的刀片)。在图1中所示的示例中，每个节点包括多个物理处理器芯片。每个物理处理器芯片(也被称为“插口”)包括多个核心，并且每个核心具有多个超线程。
如图2中图示的，系统100的物理结构形成(从底部起)超线程(230)、核心(210-224)、物理处理器芯片(202-208)和节点(102-108(其中节点104、106等从图中省略并被表示为椭圆))的层次结构。图2中描绘的树具有通过硬件配置来定义的固定大小。
如将在下面更详细描述的，每个企业超级计算机(例如，系统100)运行操作系统的单个实例。操作系统和任何应用两者都可以是标准的商业上可得的软件并且可在系统100上运行。在本文中所描述的示例中，操作系统是Linux，然而也可以使用其他操作系统，诸如Microsoft Windows、Mac OS X或FreeBSD。
在传统的虚拟化计算环境中，多个虚拟机可以在单个物理机器上运行。在图3A中描绘了这种场景。特别地，三个虚拟机(302-306)正在单个物理机器(308)上运行三个客户操作系统，该单个物理机器(308)具有它自己的主机操作系统。相比之下，使用本文中描述的技术，多个物理机器(354-358)共同地运行单个虚拟操作系统(352)，如图3B中描绘的。
在图4A中描绘了软件栈的一个示例。通常可以在传统的计算环境中使用这样的栈。在图4A中所示的栈中，应用(402)位于数据库引擎(404)之上，该数据库引擎(404)进而位于操作系统(406)上，硬件(408)位于该操作系统(406)之下。图4B描绘了在一些实施例中使用的软件栈。与图4A中所示的栈一样，应用(452)位于数据库引擎(454)之上，该数据库引擎(454)进而位于操作系统(456)上。然而，在操作系统之下且在硬件之上的是软件层(在本文中被称为超内核)，该软件层实时观察运行的系统并且优化系统资源以随着其操作匹配系统的需要。超内核在概念上统一了商品服务器集合的RAM、处理器和I/O(输入输出资源，例如存储装置、联网资源)，并且将该统一集合呈现给操作系统。由于该抽象，操作系统将具有包含处理器、存储器和I/O的聚合集合的单个大型计算机的视图。如将在下面更详细描述的，超内核优化对资源的使用。超内核也可以帮助优化诸如网络和存储装置之类的其他I/O系统资源。在一些实施例中，基于运行软件的观察和简档(profile)，关于系统的动态性能的性能指标(提示)被提供给上层(例如，数据库管理系统)，这可以进一步改进总体系统性能。
超内核可被移植(port)到所有主要的微处理器、存储器、互连、持久存储装置和联网架构。另外，随着硬件技术演进(例如，利用新处理器、新存储器技术、新互连等等)，可按需修改超内核以利用行业演进。
如图4B中所示，操作系统456正在跨一系列节点(458-462)共同地运行，其中每个节点都具有在服务器硬件上运行的超内核。具体地，操作系统正在通过由超内核的合集定义的虚拟环境上运行。如将在下面更详细描述的，用于操作系统456的视图是它正在包括个体节点458-462的所有硬件资源的单个硬件平台上运行。因此，如果每个节点包括1TB的RAM，则操作系统将具有它正在包括3TB的RAM的硬件平台上运行的视图。其他资源(诸如处理能力)和I/O资源可类似地得以对操作系统的视图共同地可用。
图5描绘了示例系统上的硬件的操作系统的视图的示例。具体地，操作系统(502)在处理器504-508和物理共享存储器510之上运行。如上面解释的，操作系统可在传统的计算系统上或者在诸如图1中所示的企业超级计算机上运行。在任一情况下，操作系统的视图将是它有权访问处理器504-508和物理共享存储器510。
图6A描绘了单个节点上的硬件的超线程的视图的示例。在这个示例中，节点具有被表示为H1(602)至H4(608)的四个超线程。每个超线程可访问物理共享存储器612的所有部分。物理共享存储器612是线性的，标记为位置0至最大量“max”。该节点也包括三级高速缓存(610)。
图6B描绘了示例系统上的硬件的超内核的视图的示例。在这个示例中，三个节点(652-656)被包括在企业超级计算机中。三个节点中的每一个均具有四个超线程、物理共享存储器和高速缓存(即，每个节点是图6A中所示的节点600的实施例)。给定节点(例如，节点652)上的超线程具有与如图6A中所示的视图相同的视图。然而，超内核知道所有节点上的所有资源(即，超内核看到十二个超线程以及所有的物理共享存储器)。在图6B中所示的示例中，给定超线程(例如，超线程658、“H1-4”)被标记有其节点编号(例如，“1”)，后面是超线程号(例如，“4”)。
图7描绘了在企业超级计算机系统的示例上的硬件的操作系统的视图的示例。操作系统将图7中表示的多个“虚拟化处理器”视为P1至Pmax(702)。虚拟化处理器对应于跨越被包括在企业超级计算机中的所有节点的超线程的总数。因此，使用图6B的示例，如果跨越三个节点存在总共十二个超线程，则总共十二个虚拟化处理器将对在企业超级计算机上运行的操作系统可见。操作系统也看到“虚拟化物理存储器”(704)，该“虚拟化物理存储器”(704)似乎是大小等于跨越所有节点的物理存储器的总量的大型物理线性存储器。
如将在下面更详细描述的，超内核基于其对系统在其正在运行时的其系统观察动态地优化高速缓存存储器和虚拟处理器布置(placement)的使用。“虚拟处理器”是为其客户操作系统所知的计算引擎，即，具有某个操作系统上下文或状态的计算引擎。如将在下面更详细描述的，“影子处理器”是匿名虚拟处理器，即，曾经是虚拟处理器但是现在已经放弃其操作系统上下文并且具有仅为超内核所知的上下文的虚拟处理器。
资源虚拟化
存储器虚拟化如上面解释的，在物理配置中，每个节点具有表示存储器中的位置的存储器地址的数组。因此，在具有三个节点的物理配置中(例如，如图6B中描绘的)，存在三个存储器位置，其中的每一个均具有地址0x123456。相比之下，在虚拟配置中，所有存储器地址是唯一的并且表示被包含在那三个节点中的所有存储器的总和。在虚拟配置中，所有存储器被共享，并且所有存储器高速缓存是一致的。在一些实施例中，存储器被进一步细分成具有单调增加的存储器地址的一系列连续块。在本文中描述的示例中，每个页面具有4K字节的存储器，然而，也可酌情使用其他细分。术语“块”在本文中被用来描述存储器位置的连续数组。在一些实施例中，“块”是“页面”。
处理器虚拟化如由操作系统看到的虚拟处理器(例如，图7的虚拟处理器706)被实现在物理配置中的超线程上，但可以是位置无关的。因此，虽然操作系统认为它有在单个物理服务器上运行的500个处理器，但是实际上它可能具有每100个处理器5个节点。(或者，如图6B中所示，操作系统会认为它具有在单个物理服务器上运行的12个处理器。)在虚拟处理器上运行的计算在该计算运行时由在超线程上的物理配置来描述，或者当虚拟处理器未运行时在“继续部分(continuation)”(即，中断或停顿计算的状态)中描述。
如本文中所使用的，“继续部分”表示虚拟处理器的状态。每个继续部分：
·具有处理器状态(即，保存的寄存器等)。
·具有按关于如何将继续部分智能地指派给叶节点以供执行的信息而指导调度器对象的性能指标的集合。
·具有指示处理器的虚拟处理器标识符，操作系统认为该处理器是将该继续部分指派到的物理处理器。
·具有该继续部分等待的事件(可能为空)。
·具有一个状态，其包括：“等待事件”或“就绪”。
I/O虚拟化
I/O系统观察对处理器和存储器的类似范例。设备具有物理配置中的物理地址和虚拟配置中的虚拟地址。当迁移计算(在下面更详细描述)时，如果例如存在与I/O操作相关联的存储器缓冲器，则所使用的I/O设备在它们和与之相关联的存储器位于一处(co-locate)的情况下将很可能表现得更好，并且可被相应地移动。
资源映射
资源映射被用来在虚拟配置与物理配置之间转换。下面是在各种实施例中由企业超级计算机使用的三种类型的资源映射。
“物理资源映射”是描述在每个节点上可用的物理资源的表。例如，它包含每个节点上的可用的处理器、设备、存储器的数量和类型及其物理地址范围等。在一些实施例中，该表是只读的并且在启动时(at boot time)是固定的。
“初始虚拟资源映射”在操作系统的启动(boot)之前是固定的并且描述从操作系统的角度看可用的虚拟资源。配置可由操作系统读取。在一些情况下，可能期望配置与底层硬件资源不一对一匹配的系统(从操作系统的角度看)。作为一个示例，可能期望操作系统具有更多的存储器和更少的核心。这可通过改变存储器与核心的比例即通过修改初始虚拟资源映射来实现。
“当前资源映射”由每个超内核实例来创建和维护。该映射从每个节点的角度来描述虚拟资源映射与物理资源映射之间的当前映射。对于虚拟资源映射中的每个条目，维护被当前指派给虚拟资源的物理资源的定义。最初(例如，在启动时)，当前资源映射是初始虚拟资源映射的副本。超内核随着时间的推移在它观察到资源负载的特性时修改当前资源图，并且动态地改变物理资源到虚拟资源的映射(并且反之亦然)。例如，虚拟机中的以太网控制器eth27的位置的定义可以在不同的时间指代不同的硬件控制器。当前资源映射被超内核用来视需要而动态地修改虚拟硬件资源映射，诸如虚拟存储器子系统。
资源迁移概要使用本文中描述的技术，可在物理位置之间迁移虚拟化资源。如上面解释的，操作系统被提供有关于虚拟化系统的信息，但是该信息不必与物理系统一致。
在以下示例中，假设企业超级计算机持有大于可装配到单个节点中的大型存储器内数据库。数据库的部分处于第一节点“节点1”中。假设不同节点“节点2”上的核心中的一个正在设法访问由节点1拥有并且并不本地驻留在节点2上的高速缓存中的数据。节点2上的核心将接收到存储器访问违规，因为它正在设法访问它认为它应该能够访问(但不能访问)的数据。如将在下面更详细描述的，该异常在超内核中被处理。
可解决该情形的一个方式是通过将存储器的所需区域移动到节点2，然后将控制返回给操作系统(其进而将它返回给数据库系统)。软件然后可按预期继续进行(即，如同从未发生过访问违规一样)。
在许多情况下，在也正在设法访问如上面节点2所需的存储器的相同区域块的其他节点(例如，“节点3”)中可以存在一个或多个其他核心。节点3可能正试图访问相同数据，或者它可能正访问被移动的、被包含存储器中的不同数据(也称为“假共享”)。数据能被移动到节点3，但是如果节点2上的核心第二次请求该数据，则将需要将该数据移回到节点2(即，可能反复地来回移动数据)，这可能是缓慢且浪费的。避免在核心之间来回移动数据的一个方式是意识到核心和数据的关联块二者应该位于一处。使用本文中描述的技术，可迁移存储器和计算，使它们驻留在相同节点上。这样做将导致更快访问的数据的更高可能性，以及共享存储在本地高速缓存中的数据的更高概率。
当发生访问违规时，超内核响应的事件被触发(以系统相关的方式)。这样的事件可被如何处理的一个示例是通过应急(panic)例程的调用。也可酌情使用其他方法。如将在下面更详细描述的，超内核检查事件的原因并且确定用于处理事件的适当的策略(例如，低级事务)。如上面解释的，处理事件的一个方式是针对超内核虚拟化存储器的一个或多个块被从一个节点的存储器转移到另一个节点的存储器。转移然后将被发起并且相应的资源映射将被更新。继续部分将被建立准备好被放置在共享存储器中被称作事件表(在下面讨论)的本地表中，使得继续部分在它被恢复时做的下一件事情将是在转移完成之后将控制返回给操作系统。也能做出将虚拟处理器移动到包含被请求的存储器的节点或者将虚拟化存储器(及其虚拟化存储器地址)从一个节点移动到另一节点的决策。在各种实施例中，超内核在处理事件时做出三个决策：哪些(虚拟)资源应该移动、何时移动它们以及应该将它们移动到哪里(就物理位置而言)。
TIDALTREE
图2中描绘的物理层次结构具有包括一组“调度器对象”(即，数据结构)的类似的软件层次结构，该组“调度器对象”中的每一个具有下面所描述的一组特性。调度器对象形成“TitalTree”，其是一种存储器内树数据结构，其中树的每个节点是调度器对象。每个调度器对象对应于超级计算机的物理结构的元素(但是不一定反之亦然)，所以存在用于整个机器的一个节点(例如，如图2中所示的节点100)、用于系统的每个物理节点的一个节点(例如，如图2中所示的节点102)、用于包括整个机器的物理节点上的每个多核心插口的一个节点(例如，如图2中所示的节点202)、用于每个插口的每个核心的一个节点(例如，如图2中所示的节点210)以及用于该核心上的每个超线程的一个节点(例如，如图2中所示的节点232)。
每个调度器对象s：
·与物理组件(例如，机架、刀片、插口、核心、超线程)相关联。
·除树的根之外，还具有部分地负责指引其操作(如在下面更详细地说明的)的父调度器对象。
·具有其中的每个都是调度器对象的一组孩子(children)。这对于叶(例如，超线程)节点来说为空。如在下面更详细解释的，调度器对象s的责任是管理并将工作指派(或者重新指派)给其孩子，并且间接地指派给其孙子等(即，s管理根在s处的子树中的所有节点)。
·具有工作队列，其是一组继续部分(如早先描述的)。
·具有(可能为空的)一组I/O设备，它也具有管理和指派(或者重新指派)工作的责任。
每个节点可潜在地与某种形式的高速缓存存储器的层相关联。高速缓存层次结构在调度器对象越高计算部分通常将越慢地高效地利用层次结构的对应级处的高速缓存意义上遵循树的层次结构。与物理节点相对应的调度器对象的高速缓存可以是与该节点相对应的存储器的高速缓存。物理节点上的存储器可被认为是虚拟机存储器的高速缓存。
资源迁移-附加的信息
超内核模拟虚拟配置在其上驻留的虚拟硬件的一部分。它是事件驱动架构，不仅涉及转换的物理硬件事件，而且涉及软事件，诸如通过在其他节点上运行的超内核代码生成的节点间超内核消息的接收。
如上面解释的，当发生对超内核有意义的中断事件时，超内核做出如何对该中断做出响应的决策。在控制被返回给操作系统之前，识别任何更高优先级中断并且采取适当的动作。另外如上面所解释的，超内核可做出三个单独的决策：(1)在某些事件时要迁移哪些资源，(2)何时迁移它们，以及(3)那些资源应该移动到哪里。
在以下示例中，假设虚拟机中的调度器对象“s”处于稳定状态。与物理节点相对应的每个调度器对象具有指派给它的一组物理处理器插口。这些插口中的超线程可能繁忙或可能不繁忙。物理节点也具有一些固定量的主存储器和一组I/O设备，包括一些网络设备。调度器对象s在与节点相对应时还负责管理被指派给根在s处的子树中的节点的网络和其他I/O设备。下面是资源在同步或异步事件时可如何迁移的描述。
通过同步事件触发的迁移
在以下示例中，假设存在叶节点调度器对象s和指派给s的虚拟处理器p。假定叶节点调度对象s代表应用来执行应用或操作系统代码。假定叶节点不在无限循环中，p由于某种原因(例如，等待I/O操作完成、页面错误等)将最终不再工作(即，停顿)。不是允许p实际地停顿，而是超内核决定是否将有关已停顿的计算的信息移动到某个其他节点，从而使该其他节点的处理器中的一个“负责”已停顿的继续部分，或者在节点上保持“负责”已停顿的计算并且替代地将相关资源移动到当前节点。
因此，通过以下两种方式中的任一种来处理停顿：要么计算被移动到当前具有资源的物理节点，要么否则资源被移动到已请求资源的物理节点。用于处理停顿的示例伪代码在下面(作为“OnStall”例程)被提供在下面的“示例例程”部分中。
诸如如何处理停顿的决策可取决于很多事情，诸如事件的到达次序、在虚拟机上运行的计算的状态、高速缓存的状态、系统或节点上的负载和许多其他事情。动态地做出决策，即，基于在任何给定时间点可用的最佳信息动态地做出决策。
记录停顿的计算
停顿的计算被记录在被称为“继续部分”的数据结构中。继续部分的状态可以是，例如，“等待事件”或“就绪”。停顿的计算得以被记录为具有状态“等待事件”的新创建的继续部分。一旦满足停顿的原因(例如，由于检测到事件)，对应继续部分的状态就变为“就绪”。具有状态“就绪”的每个继续部分被存储在调度器对象的“等待队列”中，以便最终得以调度以供执行。相比之下，具有状态“等待事件”的任何继续部分都不会被存储在任何调度器对象的等待队列中。替代地，它被存储在物理节点的本地共享存储器中，在该本地共享存储器中预期要发生使对应计算停顿的硬件事件(诸如缺失的资源的接收)。
附加地，新创建的继续部分与导致其创建的停顿事件相关联。(停顿)事件与等待这些事件的继续部分之间的这种映射允许异步事件的快速分派(参见下面描述的“handleEvent”)。继续部分与事件之间的映射被存储在叫做“事件表”的表格中，并且被保持在对应物理节点的共享存储器中。每个物理节点具有它自己的事件表，并且物理节点的事件表可由该物理节点上的每个核心直接地寻址。记录在物理节点事件表中的所有预期事件对应于在该物理节点上可能发生的硬件事件。被映射到物理节点n的调度器对象s表示n，并且n的事件表与s相关联。在某些情况下，若干个继续部分可能在等待同一事件，所以当该事件被触发时可能需要某种消歧(disambiguation)。
使用“InitContinuation”例程来构建继续部分。如果做出了要移动计算的决策，则持有资源的远程物理节点将构建与已停顿的计算相对应的继续部分，并且会将它存储在远程物理节点的事件表中。当该继续部分恢复时，资源将是可用的。实际上，超内核已将虚拟处理器转移到不同节点。
在做出要移动资源的决策的情况下，已经经历停顿的节点请求资源的转移并且使用InitContinuation来构建继续部分，并且将它存储在本地事件表中。在接收到资源时，继续部分被附连到TitalTree中的适当节点，并且当该继续部分被恢复时，资源将一般是可用且可见的。实际上，虚拟资源已被转移到请求它的节点。
注意的是，通过将继续部分放置在事件表中，保证了接收到事件的处理器将在其本地事件表中快速地找到相关继续部分。计算中的停顿的原因将得到满足。
在处理停顿后，虚拟处理器p实际上将被挂起。在处理停顿与查找要恢复的新的继续部分之间，p变成“匿名影子处理器”，即，没有为操作系统所知的身份的处理器。这个影子处理器然后寻找要恢复的新的继续部分。这样的示例在下面“assignProcessor”例程中示出，该例程在下面被更详细地描述。
表示法
让e是使虚拟处理器p停顿的事件。假定e由某个物理节点n的本地硬件触发。特别地，假定r是导致停顿事件发生的资源。资源r可以是存储器的块或I/O操作或网络操作。假定p被指派给调度器对象s，该调度器对象s属于根在表示物理节点n的调度器对象处的子树。
On-Stall
下面在“示例例程”部分中提供了用于示例on-stall例程的伪代码。当且仅当在节点n中的处理器p决定资源不应该移动即计算应该移动在情况下，迁移继续部分函数返回真。这可通过许多因数来确定，该因数诸如节点之间的r的移动的历史和频率、r的类型、移动的成本、在n的本地事件表中等待r的事件的数量、系统负载等。例如，如果在n的本地事件表中存储有正等待资源的继续部分，则移动资源可能并不合期望。
存在将受益于迁移的各种各样的模式的事件。描述事件(比如访问违规)的这些模式的一个方法是采用形式语言理论。可通过有限状态自动机来识别常规(即，乔姆斯基3型)语言。此外，使用紧凑且灵活的表示法，可使对所观察到的事件的描述成为以常规语言的句子(或乔姆斯基序列)，并且识别被建模为所对应的有限状态自动机中的状态转变。当看到完整的乔姆斯基事件序列时，迁移-继续部分得以相应地评估：如果有限状态自动机接受乔姆斯基序列，则满足条件，否则不满足。最小化的有限状态机的长度定义了需要被保持的历史的量。
在各种实施例中，所有事件在本地发生，并且接收事件的物理节点上的超内核必须处理它——真正同步事件未被假定为在物理节点之间发生。为了协调节点之间的迁移策略，“消息”被使用。消息“发送”从节点的角度看是同步的，但是消息“接收”是异步的，因为处理器或影子处理器一般而言不等待消息的接收。当消息到达时，它们被超内核作为虚拟中断来处理。在一个实施例中，当存在等待被处理的消息时，超内核将不允许处理器恢复继续部分。因此，在控制被往回转移到操作系统之前，对队列进行检查，并且在控制往回转移到操作系统之前对任何消息进行处理。
对于调度器对象s和继续部分c，可使用成本函数cost(s,c)来指导向上搜索树。如果p的多个祖先有非空队列，则p可能不想在被发现有非空等待队列的第一祖先处停止其搜索。取决于优化策略中使用的度量，p的选择可能不仅取决于p与其挑选的祖先之间的距离，而且取决于诸如等待队列的长度之类的其他参数。
可使用函数find-best-within(s)来在调度器对象的(非空)等待队列中返回“最适的”继续部分。可以考虑的参数的示例包括：
1.队列中的方位
2.p与继续部分中记录的最后位置之间的关系(那些位置越靠近，对于重新使用高速缓存条目来说可能越好)。
3.在队列中的继续部分中记录的性能指标。
可以在给定的系统内酌情定制cost和find-best-within函数。
通过异步事件触发的迁移
异步事件的示例包括：分组的接收、I/O转移的完成、资源的接收、请求资源的消息的接收等。一般地，接收与由操作系统管理的硬件设备相对应的事件的超内核需要将与该事件相关联的继续部分递送给调度器对象s。通过这样做，s将使这个继续部分对于适当的调度器对象可用，然后最终对于由通过该继续部分表示的操作系统所管理的计算可用。另一方面，如果事件是从另一物理节点上的超内核接收到消息，则超内核可直接地处理它。
为了简化解释，在本文中描述的示例中，做出了仅存在与事件相关联的一个继续部分的假定。可按需针对多个继续部分与相同事件相关联的情况来概括本文中描述的过程。
在一些实施例中，搜索要在其上放置继续部分的调度器对象在构建该继续部分的树的叶处开始，以及然后向上继续进行(如果先前在此节点上执行了计算)。通过这样做，增加了重新使用高速缓存条目的可能性。
处理事件
下面在“示例例程”部分中提供了用于示例处理事件例程的伪代码。成本函数cost(s,c)是帮助确定将c指派给调度对象s的适合性的函数。成本函数可取决于各种各样的参数，诸如等待队列的大小、s与用于c的原始调度节点之间的节点遍历距离(以增加高速缓存条目将被重新使用的概率)以及虚拟处理器、物理处理器和继续部分的历史。如果靠近s的调度器对象的等待队列已经包含太多继续部分，则在任何新添加的继续部分被调度以供执行之前可能花费相对较长的时间。在下面描述了有助于cost(s,c)的示例条件，并且可酌情定制这些条件。
成本
成本函数被用来在选择继续部分和调度对象时评估选项。可将成本函数表达为加权因数的和的求和：
cost＝w1f1 x 1+w2f2 x 2+...+wnfn x n，其中wi指示对应因数的重要性并且xi指示指数。
因数fi的示例针对下面的每个成本而列出。可以各种各样的方式(诸如凭经验和通过模拟)确定权重wi和指数xi。初始权重和指数可被调谐以满足各种应用需要，并且可由管理员调整来增加性能。可以在系统活动的同时调整权重，并且改变权重不改变超内核的语义，仅改变操作性能特性。
可以考虑的因数的示例包括：
·自最后处理器撤出该调度器对象以来的时间的长度。
·TitalTree中的调度器对象的高度。
·工作队列的长度。
·保留状态(即，情况可能是某个应用由于特定原因而已保留该资源)。
·节点规范(即，节点本身可能已被停用或者是有问题的、在某种程度上具有专门功能等)。
·队列中的继续部分的年龄。
·要运行该继续部分的最后的物理处理器。
·要运行该继续部分的最后的虚拟处理器。
·最后执行该继续部分的节点。
·高速缓存的“温度”。(当高速缓存具有很可能被重新使用的条目时，该高速缓存是“温暖的”。当高速缓存不太可能具有可重新使用的高速缓存条目时，该高速缓存是“冷的”。)
·继续部分的组成员关系(即，继续部分可以是计算组的部分，其中的每个元素对于该组的其他成员来说具有某种亲和性(affinity))。
·性能指标(提示)和特殊要求。
示例
“OnStall”和“assignProcessor”
图8图示了用于选择性地迁移资源的过程的实施例。在一些实施例中，过程800由超内核诸如结合OnStall例程来实行。在接收到核心(或包括在核心中的超线程，这取决于处理器芯片是否支持超线程)被阻塞的指示的情况下，过程在802处开始。作为一个示例，假设超线程直接地或间接地接收到对超线程不能够访问的资源(例如，位于与持有超线程的节点不同节点上的RAM)的请求。当超线程未能访问资源(即，发生访问违规)时，在802处发生由超内核拦截、捕获或者以其他方式接收的中断。特别地，超内核在802处接收超线程被阻塞(因为它不能访问已被指令以提供的资源)的指示。除了报告其阻塞状态之外，超线程还提供诸如它被指令以访问的存储器地址以及尝试什么类型的访问(例如，读取、写入或修改)之类的信息。
在804处，超内核确定是否应该移动所需存储器(例如，移动到阻塞的超线程位于其上的节点)，或者请求过程是否应该被重新映射(即，虚拟处理器应该被转移到不同节点)。决策可以基于各种各样的因数，诸如所需存储器位于之处、高速缓存的温度、持有超线程的节点上的工作负载以及持有所需存储器的节点上的工作负载(例如，工作过度或工作不足)。在一些实施例中，至少部分地基于TitalTree中的平均队列长度来确定节点的工作负载。
如果超内核确定应该移动存储器，则超内核使用其当前资源映射来确定哪一个节点很可能持有所需存储器并且向该节点发送消息，从而请求资源。超内核也创建继续部分并且将它放置在其事件表中。在802处被阻塞的超线程因此被释放以承担其他工作，并且可以被指派给使用assignProcessor例程的另一个虚拟处理器。
超内核在高优先级基础上检查其消息队列。当超内核从它联系的节点(即，“第一联系节点”)接收消息时，在一些实施例中，将接收两个响应之一。响应可能指示第一联系节点具有所需资源(并且提供该资源)。替换地，消息可能指示联系节点不再具有资源(例如，因为节点将资源提供给不同节点)。在后者情形下，第一联系节点将提供它将资源发送到的节点(即，“第二节点”)的身份，并且超内核可以发送请求资源的第二消息——这次发送到第二节点。在各种实施例中，如果第二节点向超内核报告它不再具有资源(例如，已将其提供给第三节点)，则超内核可以选择将继续部分发送到第三节点，而不是继续请求资源。可以在确定是发送继续部分还是继续进行该资源(例如，四次尝试)时使用其他阈值。另外，可以在确定是请求资源还是发送继续部分(例如，根据成本函数)时使用各种各样的准则。
如果超内核确定应该转移继续部分(即，应该将计算发送到另一个节点而不是在本地地接收资源)，则超内核给远程节点(即，具有所需资源的远程节点)提供该远程节点可以用来在它自己的物理地址空间中构建继续部分的信息。如果远程节点(即，接收继续部分的远程节点)具有它需要的所有资源(即，拥有导致初始访问违规的资源)，则不需要将继续部分放置到远程节点的事件表中，而是可以替代地放置在其TitalTree中。如果远程节点需要附加资源来处理继续部分，则所接收到的继续部分被放置在远程节点的事件表中。
图9图示了用于实行分层动态调度的过程的实施例。在一些实施例中，过程900由超内核诸如结合assignProcessor例程来实行。在接收到应该指派超线程的指示的情况下，过程在902处开始。可以用多种方式调用过程900。作为一个示例，当超线程可用(即，无当前工作要做)时，可以调用过程900。例如，当超内核确定(例如，在804处)应该进行继续部分时，这可以发生。先前阻塞的超线程将变得可用，因为它不再负责处理它在其上被阻塞的计算(即，超线程变成“匿名影子处理器”)。作为第二示例，当(例如，由超内核)接收到先前不可用的资源现在是可用的消息时，可以调用过程900。超内核将需要定位超线程来恢复需要资源的计算。注意的是，最初因缺乏资源而被阻塞的超线程不必是一旦接收到资源就恢复计算的超线程。
在904处，针对准备运行的继续部分来搜索TitalTree，并且为要恢复的超线程选择一个。在各种实施例中，从叶级向上搜索TitalTree，并且使用成本函数来确定要将哪一个继续部分指派给超线程。作为一个示例，当超线程变得可用时，可以指派已经排队达最长时间量的继续部分。如果没有继续部分在叶级等待，或者在由成本函数指定的阈值之外，则将实行在TidalTree上(例如，核心级，然后插口级，然后节点级)的搜索以得到适当的继续部分以指派给超线程。如果没有找到适当的继续部分以用于超线程在节点级恢复，则该节点的超内核将联系根。在节点级没有找到继续部分的一个典型原因是不存在该节点被充分利用的足够工作。在一些实施例中，节点或节点的子集可以进入节能状态。
时间序列
出于说明目的，在该示例中，使用“交换”操作来转移继续部分和存储器，但是实际上这并非在所有实施例中都是必需的。
图10图示了初始存储器指派和处理器指派的示例。具体地，图10的区域1002描绘了存储器的物理块(在左侧)与存储器的当前所有者(中心列)之间的超内核的映射。右列示出了存储器的先前所有者。当这是初始存储器指派时，当前和最后的所有者列持有相同的值。图10的区域1004描绘了系统虚拟处理器(在左侧)与物理节点(中心列)/核心编号(右列)之间的超内核的映射。
假设虚拟处理器P00做出读取位置8FFFF的存储器请求，并且超内核决定将包含8FFFF的一个或多个存储器块移动到与P00相同的节点(即，节点0)。块8FFFF位于节点2上。因此，包含8FFFF的块被转移到节点0，并且另一块被换出(如果需要撤出并且块有效的话)，如图11中所示。
接下来，假设虚拟处理器P06做出读取位置81FFF的存储器请求。该块的内容已被移动(如图11中所示)到节点0。超内核可以确定，不是再次移动存储器，而是应该移动计算。因此，虚拟处理器P06被移动到节点0，并且可以与虚拟处理器P01交换，如图12中所示。
性能信息
锁和其他同步器
在各种实施例中，像锁一样的同步机制的使用是最小限度的。锁例如被用来插入队列并且移除调度器对象上的队列继续部分以及来维护事件表。
代码路径长度在一些实施例中，所有代码路径的(最大)长度是通过静态代码分析确定的，从而导致在超内核本身中花费可估计且受约束的时间量。所有数据结构可以例如被预分配为索引数组。TidalTree的节点在启动时确定并且是不变的，其遍历中的步数也是不变的。一个可变长度计算与工作队列的长度有关，但是即使那样也可以是受约束的，以及与计算的最坏情况的估计有关。在其他实施例中，使用其他可变长度计算。
静态存储装置在各种实施例中，超内核中需要的所有数据结构是静态的，并且在启动时确定，所以不需要动态存储器分配或垃圾收集。
物理存储器由超内核使用的所有存储器是物理存储器，所以针对其内部操作不需要页表或虚拟存储器(除了例如管理它正管理的虚拟资源)，从而进一步帮助超内核与操作系统共存。
共享数据以及维护一致性
在一些情况下，例如，为了保存被呈现给操作系统的虚拟机的概念完整性，一个节点的数据结构中的变化与不同节点中的对应数据结构协调。本文中描述的许多数据结构是“节点本地的”，并且或者将不需要移动，或者是不变且被复制的。节点本地的数据结构对节点上的所有超线程可见并且可由节点上的所有超线程寻址。非节点本地的(并且因此需要协调)的数据结构的示例包括当前资源映射(或其部分)、TidalTree的根和迁移的继续部分(即，可能必须从一个节点逻辑上移动到另一节点的继续部分)。
可以使用各种各样的技术来维护足够程度的一致性。一些是同步的并且假定所有变化同时对所有节点同时可见(即，“立即一致性”)。其他的允许更宽松的解决方案并且努力实现“最终的一致性”。如上文提到的，企业超级计算机的物理节点经由一个或多个高速互连连接。超内核的多个实例互连以在物理节点之间来回传递消息和资源。
更新当前资源映射
每个物理节点n从物理资源映射、初始虚拟资源映射和当前资源映射的相同副本开始(例如，在启动时)。每个节点维护它自己的当前资源映射的副本。
在一些实施例中，当前资源映射中的资源r的每个条目具有以下：
1.本地锁，使得物理节点上的多个超线程不能同时修改r。
2.指定当前拥有资源的节点的节点编号。
3.自从其上一次拥有r之后，已经请求r的次数n的计数k。
4.当置位时表示此节点n想要r的布尔值。
5.当置位时表示此节点具有r但是在转移它的过程中的布尔值，在此情况下节点编号指定新的所有者。
在一些实施例中，计数k被用来处理对资源的无约束追逐。如果k超过阈值，则做出最好是移动新构建的继续部分而不是围绕系统追逐资源的确定。
下面是用于发起资源的迁移并且接收资源的机制的示例。关键事务包括以下：
1.节点n向n'发送对资源r的请求。
2.节点n'从n接收对资源r的请求。
3.节点n'可以在某些情况下向n发送“拒绝”消息，否则它可“接受”并且将会发送资源r。
4.如果资源r不能由n'在此时间点发送，则节点n将从n'接收到“拒绝”消息。这可能是因为n'需要r，或者这可能是因为r在请求到达时正在向别处转移。如果请求被拒绝，则它可以发送它正向其转移资源的节点的“转发”地址。转发地址可能是n'本身，这相当于“稍后再试”。当节点n接收到拒绝消息时，它可以将请求重新发送到n'建议的节点，其通常是资源的新所有者。为了避免n围绕系统追逐资源，它可以跟踪要得到资源的尝试次数，并且在尝试次数超过阈值时切换策略。
5.如果n'可以发送资源，则节点n将接收资源r。在这种情况下，n需要调度等待r的继续部分c，使得可以恢复c。
TidalTree根
在一些实施例中，系统中的一组节点的一个物理节点被指定为“主节点”。此节点在启动时负责构建初始虚拟资源映射和其他数据结构，将它们复制到其他节点以及启动操作系统(例如，Linux)。在具有一个例外的情况下，在系统被启动之后，主节点就可以像任何其他节点一样。至少一个物理节点需要存储TidalTree的根。主节点是可以放置根的地方的一个示例。对TidalTree根调度对象的事件队列的更新是在每个节点中通过向主节点发送消息以实行更新来进行处理的。
随着时间的推移，如果操作系统和应用的资源访问模式允许，超内核将适应并且局部性(locality)将不断地改进。
继续部分
如上面解释的，跨越所有节点的物理存储器地址不是唯一的。在一些实施例中，可以通过使用分区整数索引以标明超内核中的重要数据结构来避免在继续部分中包括物理存储器地址。如果需要将地址放入继续部分，则在移动时要当心，因为地址是源的物理地址，并且与目的地中的物理地址没有关系。移动继续部分意指像上面所讨论的那样将其内容复制到目的地节点，并且将任何物理地址从源重新映射到目标。
时间戳
在一些实施例中，对自由运行计数器的访问对所有节点是可见的。如果没有这一点，也可以使用每个节点上的自由运行计数器。继续部分中的计数器被映射在源与目的地之间。
磁盘和持久闪存的处理
在所需资源在磁盘(或持久闪存)上的情况下，在一些实施例中，这样的资源被视为具有比诸如RAM之类的资源更重的重力场。因此，磁盘/闪存资源将往往不很经常地迁移。替代地，根据需求，继续部分将更频繁地迁移到包含所需持久存储装置的物理节点，或者迁移到与持久存储装置相关联的缓冲器。
操作系统配置存在配置操作系统的许多方式。对于服务器，可以做出下述假定，即其操作系统被配置成仅需要来自由超内核实现的虚拟机的一小组资源类型：包括线性块数组的存储装置、网络、处理器、存储器和节点间互连。作为结果，可以降低操作系统安装的复杂性。
示例数据结构和函数
以下部分提供了在各种实施例中使用的数据结构和函数的示例的列表。
/>
/>
/>
/>
/>
/>
在上文中，描述了各种实施例，其中示出了如何创建、管理和优化分布在紧密互连的一组物理服务器(或计算机)上的虚拟服务器(或计算机)的实例。
为了使这样的系统有效运行，客户物理处理器组(vcpu)与存储器的虚拟页面集(客户操作系统认为是物理页面的存储器的客户物理页面)相关联，使得它们可以跨一组计算机(例如，集群中的节点)位于一处。当位于一处时，微处理器中的虚拟化硬件可以被用来实现与基于硬件的非虚拟化服务器一致的性能水平。
vcpu对客户物理存储器页面集的页面访问模式由应用程序、操作系统、网络、实时事件、I/O设备等的组合来定义，并且如果构建真正的虚拟化服务器则不会改变。
现代操作系统(诸如Linux、FreeBSD、Windows和Mac OS)提供了一组特征来实现被称为“线程”的异步控制结构。线程是操作系统或运行时间库(或两者)中的软件结构和机制，其允许异步和并行程序行为，通常包括对异步中断的响应。线程允许子程序在不同时间运行具有不同数据访问模式的不同指令流。在本文中描述的示例中，线程可以在客户操作系统中运行的调度器的控制下被绑定到一组虚拟处理器。在任何给定的时间点，线程(例如，与在客户操作系统上运行的应用相关联的客户线程)正在vcpu上运行或根本不运行。稍后，调度器可以决定在不同的物理处理器上运行线程。
如上所述，虚拟化环境中的vcpu可以在整个虚拟机和虚拟机的调度器(可以与客户操作系统调度器不同)的实现方式中绑定到真(也称为“主机”)物理处理器。
现代操作系统通常可以向硬件或虚拟化系统提供关于在任何给定时间点哪个线程在哪个vcpu中运行的信息。
操作系统假定它可以直接且快速地访问系统的所有资源(例如，存储器、I/O、网络等)。在跨越使用本文中描述的技术所构建的一组节点的单个虚拟机中，该假定在语义上被保留，但物理实现可能不是真实的。例如，可能存在访问非本地资源的虚拟处理器(或线程)，其中该非本地访问既不是直接访问也不是快速访问。如上所述，当虚拟化系统观察到来自不可物理实现的客户的事件时，生成停顿。虚拟化系统运行以纠正或以其他方式解决下述情形，该情形导致停顿以使其符合客户(操作系统)所期望的语义行为。虚拟化系统的性能由客户操作系统的基本性能控制，但可能会因停顿的数量以及使停顿在语义上准确所花费的总时间而降低。使用下面描述的技术，可以在虚拟化系统中减少停顿的数量以及每个停顿的平均时间。
在上文中描述了用于跟踪虚拟处理器和虚拟页面集的使用模式的示例技术，以及做出关于通过分布式虚拟环境迁移虚拟处理器和虚拟页面的决策。可以细化和扩展或以其他方式适配上述技术，以跟踪访问存储器页面集的线程集的访问模式。
跟踪线程和相关联的存储器页面集可以基于下述观察：虚拟处理器和存储器页面集的访问模式实际上由在客户操作系统调度器的控制下运行在虚拟处理器中的客户线程确定。客户线程可以在不同的时间在不同的虚拟处理器中运行，因此也可以在主机物理处理器中运行。Vcpu以及因此主机物理处理器可以在不同的时间点运行相同的客户线程。
线程与主机物理处理器的绑定取决于各种各样的因素，其中可包括客户调度器的编程行为、由线程实行的计算、外部异步事件的模式(诸如网络分组的到达)、I/O中断的完成等。这些事件以及因此事件到达的模式和客户线程与客户物理处理器的绑定可能无法预先预测。因此，即使程序运行是确定性的，系统的行为也可能是非确定的。
通过检查线程，可能不先验地知道哪个线程正在哪个vcpu中运行，因为这处于客户操作系统或客户运行时间库的控制之下。然而，如下面将进一步详细描述的，操作系统提供各种机制(或提示)以确定在任何给定时间点哪个线程在每个虚拟处理器中运行。这样的信息可以被用在虚拟处理器(vcpu)的基本调度和迁移决策中。如下面将进一步详细描述的，使用本文中描述的技术，虚拟处理器(运行客户线程)可以与同一节点上的适当的虚拟存储器(客户物理存储器)页面集尽可能多地保持在一起。通过这样做，可以减少由于非本地访问所致的停顿，并且可以实现与真实物理计算机相当的性能水平。此外，可以减少开销(例如，停顿数量和每个停顿的平均时间的乘积)。这可以通过将页面和线程智能地放置在它们最可能不会停顿之处来实现。页面转移和页面迁移的数量也可以被最小化。
页面可能驻留在节点上，因为需要读取页面。页面也可能在节点上，因为需要写入页面。在一些实施例中，只要节点都在读取页面，则多个节点就可以具有页面的本地副本。当需要写入页面时，在除了进行更新/写入的节点之外的节点上实行页面的所有副本的无效。在一些实施例中，当更新完成时，其他节点然后可以在再次需要读取页面时要求/请求页面的副本。
用于管理线程与引用页面集之间的关系的技术将在下面进一步详细描述。使用本文中描述的技术，给定页面p，确定哪些线程强烈需要p。此外，给定线程t，确定t强烈需要哪些页面。作为一个示例，当线程在vcpu中运行时，如果线程停顿(因为它在引用不驻留在该线程正运行的节点上的页面)，则实行停顿直到页面到达。停顿是此线程需要此页面的指示。例如，通过计数给定线程停顿以获取对页面的访问的次数的频率，无论线程在哪个节点上运行，都可以跟踪并且可以管理这样的信息。被确定为线程所需的页面被包括在与该线程相关联的页面的工作集中。线程可以在线程级别的基础上被跟踪或识别，因为操作系统可以提供机制或提示以确定在任何给定时间哪个线程正运行每个虚拟处理器。
图13A是其中线程和工作集相关联的环境的示例实施例。使用下面描述的技术，可以确定给定客户线程最感兴趣的页面。对于虚拟化系统中的每个客户物理页面，还可以确定在给定页面中最感兴趣的线程。虽然下面描述的示例实施例涉及Intel虚拟化硬件(例如，Intel VT-x)，但是本文中描述的技术可以被以各种形式适配成适应任何类型的虚拟化硬件(例如，AMD AMD-V)。
在图13A的示例中，客户应用1302在客户操作系统1304之上运行，该客户操作系统1304进而跨形成企业超级计算机(例如，系统100)的一系列个体物理节点1306共同地运行。更具体地，客户操作系统在由超内核的合集定义的虚拟环境上运行，如结合图4B所描述的。
如上面结合图7所述，从客户操作系统的角度来看，客户操作系统看到多个“虚拟化处理器”(本文中也被称为“虚拟处理器”或“vcpu”)，它们对应于跨被包括在企业超级计算机中的所有节点的超线程的总数。操作系统也看到“虚拟化物理存储器”(在本文中也被称为“客户物理存储器”)，其似乎是大小等于跨所有节点的物理存储器的总量的大型物理线性存储器。在这样的虚拟配置中，来自客户视角的所有存储器地址(在本文中也被称为“gpa”的“客户物理地址”)是(全局)唯一的，并且表示形成企业超级计算机的节点中所包含的所有存储器的总和。gpa在整个集群中是唯一的(无论节点如何)，其中客户物理地址空间是由客户操作系统(客户OS)定义的大且扁平的地址空间。
在图13A的示例中，客户应用1302与虚拟地址空间相关联。例如，当客户操作系统1304启动客户应用1302时，客户OS为该应用创建虚拟地址空间(例如，设置页表)。每次执行客户应用时，都会创建新的页表。客户应用1302还具有线程集。在该示例中，客户应用1302是单线程的并且具有单个线程1308(这里也被称为“客户线程”)。其他应用可具有多个线程(即，应用可能是多线程的)。在此示例中，客户线程正在vcpu上运行。vcpu进而在物理节点上的物理处理器(在本文中也被称为“pcpu”)上运行或执行，该物理节点诸如企业超级计算机的物理配置中的超线程。客户线程(与vcpu一样)在整个群集中是全局唯一的。
当客户应用1302正在运行时，客户线程引用应用的虚拟地址空间中的虚拟页面。为了获得由客户应用引用的存储器的物理页面(并且客户线程需要该客户应用来继续其计算)，在虚拟化环境中实行两级动态地址转换。通过为支持虚拟化的那些处理器打开虚拟化，自动实行两个级别的动态转换(即，如果打开虚拟化，则每次引用地址时，就实行两步地址转换——如果虚拟化系统没有正在运行，则将不实行第二级地址转换)。
图13B图示了虚拟化环境中的动态地址转换的示例。在该示例中，在应用级别，内部vcpu状态使用第一级页表1310(由客户操作系统管理)实行第一级页面地址转换，其将虚拟存储器地址(用于存储器的页面)1312转变成客户物理地址1314。在一些实施例中，第一级页表是具有各种条目的存储器块，其中第一级页表由客户操作系统写入并且由硬件读取。不同的应用将在两个不同的虚拟地址空间中运行(并且在客户级别，每个应用将具有其自己的第一级页表，其将其各自的虚拟地址空间中的每一个映射到客户物理存储器/地址空间)。例如，虚拟存储器地址被用作到第一级页表中的索引，以获得对应的客户物理地址。因此，虚拟地址已被转变成客户操作系统认为是“物理地址”的内容(但从超内核的角度来看实际上是客户物理地址)。
响应于查找第一级页表而返回的客户物理地址(或gpa块，其可以是例如64位值)然后由物理处理器的虚拟化硬件用作对第二级页表1316的索引，以获得存储器的对应物理页面(例如，4K物理存储器地址)。可以在硬件中设置第二级转换表，以将客户物理地址映射到“真实”物理地址1318(驻留在集群节点上的存储器的实际物理页面)。虽然在客户OS上运行的每个应用都有其自己的第一级页表，但是第二级页表在客户操作系统认为是物理存储器的同一存储器池外运行。
第二级页表特定于每个节点，其中企业超级计算机中的每个节点与对应的第二级页表相关联。虽然每个节点与其自己对应的第二级页表相关联，但是可以使用客户物理地址以相同的方式索引所有页表，如上所述，客户物理地址在整个超级计算机集群中是全局唯一的。如果对应于客户物理地址的存储器的页面驻留在节点上，则在节点的第二级页表中将存在对应的条目。
图13C图示了实行第二级地址转换的示例实施例。在该示例中，存储在vcpu状态的CR3寄存器中的客户物理地址(1314)(下面进一步详细描述)被用来索引第二级页表1316以获得对应的4K物理存储器地址1318，其指向节点上的物理存储器1320的实际页面，已假定vcpu身份的pcpu驻留在该节点上。在该示例中，因为所请求的页面对于节点是本地的，所以在第二级页表中存在与客户物理地址相对应的有效条目，然后可以由客户线程获得并使用真实物理存储器的页面。
如果对应于客户物理地址的存储器的页面对于节点不是本地的，则该节点的第二级页表将不包括客户物理地址的条目(例如，其中该条目被清零或已被无效)。因此，可以确定对应于所引用的客户物理地址的真实物理页面在节点上不是本地可用的。页面在某个时间点处于节点处，并且由超内核迁移到另一个节点(在这种情况下跟踪页面的位置)，或者根本没有在节点上看到该页面(例如，虚拟化系统可以是新启动的)。在页面已从节点迁移出来的情况下，则第二级页表中的条目将被清零或无效，以便处理器不会查找该节点上的物理页面(因为它已被移动到别处)。
如上所述，当由于存储器的页面不可访问而发生停顿事件时，可以将所需页面迁移到需要存储器的节点，或者可以迁移vcpu。在移动页面时，会移动其内容，这包括在目标节点处分配物理页面，以及将页面内容复制到新节点。还更新了目的地上的第二级页表，以便使用新迁移的物理页面填充与gpa对应的条目。因此，下次引用页面时，不会生成错误。如果迁移了vcpu，则会在具有引用存储器的页面的节点上重新构建它。由于客户物理地址在虚拟化系统中是全局唯一的，因此当迁移的处理器访问其新节点的第二级页表时，将找到与引用的gpa相对应的有效条目(即，对节点上的所有二级页表的索引都是相同的或不变的，因为它们由全局唯一的gpa索引)。
因此，通过实行两级地址转换，客户线程引用的虚拟地址被转换成客户物理地址，而客户物理地址进而转换成真实物理地址(如果引用的存储器页面与正在运行vcpu的pcpu在相同的节点上，vcpu进而运行访问存储器的页面的客户线程)。如果请求的真实页面在节点上，那么它将处于第二级页表中，并且不会发生停顿。访问实际的存储器页面，并且客户线程可以继续其处理。
然而，假设对应于客户线程所需的客户物理地址的存储器的真实物理页面对于客户线程当前在其上运行的节点不是本地的，其中对应于客户物理地址的条目不存在于第二级页表中或者是无效的或被清零。
在该示例中，生成机器故障——即，发生停顿事件。在停顿时，运行客户线程的vcpu进而在pcpu中执行。因此pcpu将停顿。这导致生成了中断。该中断经过指向超内核的中断向量。超内核捕获该中断，该超内核执行一组例程。在该示例中，例程的执行会导致保存pcpu的状态。作为一个示例，当发生停顿时，执行获得物理处理器状态的块的指令。物理处理器状态的状态对应于物理处理器已假定其身份的vcpu的状态(其中超内核维护物理处理器到虚拟处理器的映射，并且因此可以将物理处理器的状态映射到特定vcpu的标识符)。处理器状态的块被保存到存储器的区域。保存物理处理器块状态的功能可以由微处理器硬件架构提供(例如，由通过硬件提供的宏)。在该示例中，状态信息的保存是由硬件架构提供的管理程序(hypervisor)所提供的软件指令，其维护/跟踪物理处理器上的多路复用。
在一个实施例中，保存的处理器状态是在创建继续部分时所保存的vcpu的状态，如上所述。处理器状态可以包括各种寄存器、程序计数器等。在停顿期间，调用的例程集也被用来确定在vcpu中运行的客户线程的身份和/或由客户线程引用的客户物理地址的身份。例如，如下面将进一步详细描述的，可以通过访问在停顿期间保存的处理器状态中的某些寄存器来实行识别。因此，可以确定并记录物理处理器正在运行的内容(其本来是客户线程)，以及处理器在尝试访问存储器时处理器使用的页表。通过获得这样的身份信息，可以确定线程与存储器的页面之间的关联。
确定线程身份如上所述，保存了vcpu(其已经在pcpu上运行)的处理器状态。在此示例中，如下确定在vcpu中运行的客户线程的身份(物理处理器已假定其身份)。获得FS-Base0寄存器中的值。
在客户操作系统中，每个线程具有留出的存储区域或数据结构，其包括特定于给定线程的线程本地存储装置(其可以由线程库放置就位)。FS-Base0寄存器值包括针对特定线程的线程本地存储装置的指针。线程本地存储装置还可以与内核信息相关联。FS-Base0寄存器由客户操作系统管理。
设置FS-Base0寄存器值，使得两个不同的线程将具有不同的FS-Base0值(即，对于线程T1不等于线程T2而言，线程T1的FS-Base0不等于线程T2的FS-Base0)。因此，fsbase寄存器中的值可以被用来唯一地标识在vcpu中运行的客户线程。
确定客户物理地址由客户线程引用的客户物理地址空间可以从保存的处理器状态中的寄存器获得。在该示例中，通过访问处理器状态的已保存块的内部CR3寄存器中的值来获得线程在其上停顿的页面的gpa的身份。CR3寄存器值指示客户操作系统使用哪个表来映射地址，其中CR3寄存器中的值定义客户操作系统所看到的地址空间(客户物理地址空间)。例如，CR3寄存器包括到用于节点上所有客户物理地址的第二级页表的指针，其中CR3指代特定的地址空间(当运行新的客户应用或过程时，新的CR3地址空间被生成)。如上所述，第二级页表被用来将gpa转变成真实物理地址。例如，由物理处理器(以作为特定的vcpu的身份)通过使用CR3寄存器中的gpa值索引第二级页表来实行地址转换。作为一个示例，从CR3寄存器获得的客户物理地址的前几位被用作到第二级页表中的索引(例如，CR3寄存器的前20位是存储第一页目录条目的物理地址的页面目录基址寄存器，其中CR3允许处理器通过在启用虚拟寻址时定位适当的页面目录和页表来将线性地址(gpa)转换成物理地址。可以通过掩蔽低阶位并且取高阶位来获得前几位。这些高阶位指示客户物理地址所引用的4K页面中的哪一个(可能不需要所有比特)。虽然第二级页表在每个节点上不同，但是gpa在所有节点上都是唯一的，并且可以被用作任何第二级页表的全局指数。
如上所述，如果页面在节点上，则将返回所请求页面的真实物理地址(即，当CR3寄存器值被用来索引第二级页表时，在第二级页表中将存在真实物理地址的对应条目)。如果节点上不存在存储器页面，则将发生停顿(因为CR3寄存器值的索引处的条目将被清零或无效)。
线程上下文切换
在上面的示例中，当请求的存储器页面在节点上并非本地可用时，会采取停顿。在vcpu中运行的客户线程的身份和/或vcpu引用的客户物理地址空间是根据响应于停顿而保存的处理器状态的块来确定的。当由于其他事件发生停顿时，也可以实行线程/页面标识。例如，当发生线程上下文切换时，也可以调用停顿。客户操作系统可以实行线程上下文切换，其中操作系统将客户线程切换、移动或多路复用到不同的vcpu中。当切换vcpu中的线程时，这会导致对vcpu的FS-Base0寄存器值的对应改变(例如，当发生线程上下文切换时，FS-Base0寄存器被切换或更新成对应于新线程的新值)。
管理程序可以反思(introspect)客户操作系统中正发生的内容，以确定在vcpu容器中运行的线程的身份。可以利用管理程序的部分来跟踪在pcpu上实行的多路复用以及用于维护处理器状态的块。例如，当发生内部寄存器改变时，可以在管理程序中捕获线程的跟踪，诸如由于如上所述的线程上下文切换而改变的FS-Base0寄存器值。在一些实施例中，当检测到FS-Base0寄存器中的改变时，调用停顿，使得超内核现在知道vcpu正在运行不同的线程。
例如，假设客户操作系统正在特定的vcpu中运行过程。客户OS现在将该过程切换到不同的vcpu，因此更新FS-Base0寄存器。对FS-Base0寄存器的更新触发了停顿，这唤醒了超内核(其中超内核被配置成被警告或通知FS-Base0寄存器值更新)。超内核被配置成确定FS-Base0寄存器的先前值是什么，和/或观察新的FS-Base0寄存器值。基于这样的观察，可以识别线程上下文切换。在由线程上下文切换调用或触发的停顿期间，可以确定vcpu中/由vcpu引用的存储器的线程和/或页面的身份，如上所述。
内核/用户空间
客户操作系统可能在停顿时运行用户空间代码或内核空间代码。如果客户OS正在运行用户空间代码，则将填充FS-Base0寄存器以指向正在运行的客户线程，如上所述。
如果正在运行内核代码，则特定值(例如，零)将在FS-Base0寄存器中，指示正在运行内核空间代码(而不是客户线程/客户操作系统代码)。例如，假设客户操作系统从在用户空间中运行切换到内核空间。如上所述，两个空间之间的变化导致可以检测到的FS-Base0寄存器中的变化。CR3寄存器也可能改变，并且指向内核地址空间。
当在内核空间中发生停顿时，也可以获得线程/工作集见解(insight)。作为一个示例，假设由于FS-Base0寄存器值变为零而检测到对内核空间的改变。如果CR3值没有改变，则由物理处理器在完成的工作可以与具有匹配的CR3值的线程相关联或归因于该具有匹配的CR3值的线程。因此，可以在切换到内核空间发生时确定由客户线程(在用户空间中操作)完成的工作。因此，无论是在内核空间还是用户空间中，工作集见解都可能在任何停顿上发生。
通过确定线程访问的客户物理地址(也可以如上所述而被识别)，可以确定线程之间的关系。例如，由于CR3寄存器中的地址是全局唯一的客户物理地址，如果两个线程具有相同的CR3值，则确定线程在相同的客户物理地址空间中操作(例如，两个线程正共享相同的地址空间)。这指示两个线程密切相关(例如，它们有可能共享相同的页表)。
因此，使用上述技术，确定了什么具体线程正运行在哪个具体客户物理地址空间中。随着停顿事件随时间的推移而发生，可以识别或以其他方式确定由线程引用的存储器的客户物理页面的模式或集合(即，“工作集”)(其中存储器访问的模式是线程相关的，与取决于vcpu相对)。因此，对于每个线程，可以确定给定线程感兴趣的页面。此外，对于每个页面，还可以确定什么线程对给定页面感兴趣。
记录历史
在识别与停顿的vcpu相关联的客户线程和/或客户物理地址时，可以将所识别的信息记录在历史中。对于给定的线程，记录线程访问的页面。对于给定页面，记录访问该页面的线程。在一些实施例中，记录每次客户线程访问客户物理页面。访问可能导致命中(hit)(如果页面在本地可用)或未命中(miss)(页面是非本地的)。无论页面访问是命中还是未命中，都记录客户线程访问的页面的标识符(即，记录命中和未命中两者)。与访问相关联的时间戳也可以被记录为历史信息的部分。历史可能会随着时间的推移而更新。例如，随着由虚拟化机器实行的处理的进行，线程和存储器的计算状态和存储器访问模式的状态随时间的推移而变化和演变。因此，线程与工作集之间的关联可以随时间的推移动态地改变。
表征存储器与线程之间的关系的信息可以被用在超内核中的若干位置，诸如存储器内务处理(housekeeping)、TidalTree决策制定、成本函数决策、从远程节点接收资源请求等，如将在下文中进一步详细描述的。
在一些实施例中，设计API，其具有允许评估和维护线程与页面之间的关系的行为，并且指导在其决策制定中最大限度地利用这些关系的超内核行为。
下面描述的是可以被用来在本文中描述的虚拟化系统的处理中做决策的示例成本项(cost term)和度量的列表。关于在何处以及如何利用成本项的另外的细节(例如，在内务处理、TidalTree决策、成对资源迁移协商中等)将在下面描述。
存储器状态
在一些实施例中，对于给定线程T、节点n和时间t，记录在t之前的某个时间段期间T在节点n上访问的页面集H，假定在该时段期间T正在该节点上运行。记录的页面集被称为在时间t时在n上T的页面访问历史H、t、n。在实践中，H、t、n可以表示对于某个持续时间δ，在时间间隔[t-δ，t]期间T在n上访问的所有页面的合理子集近似。在一些实施例中，使用该近似是因为没有硬件支持，在不产生非常大量的开销的情况下，可能在计算上难以记录线程的每一次访问。如果硬件支持可用，则可以使用它来记录线程访问。在一些实施例中，不是指代非恒定增量，而是可以依照间隔的可变长度(例如，[t1...t2]或[t3...t4])来表示上述时间。
温暖(warmth)和利用率(utilization)
对于每个历史H、t、n，维护两个度量——利用率和温暖。在一些实施例中，利用率(其也可被称为相关性)将在过去的某个时间t记录的历史H、t、n与客户线程T的最近页面访问模式(即，它的新历史H、t'、n)相关联，后者发生在更近的过去[t'-δ'，t']，其中当前时间t'>t，并且针对某个δ'。如果在t'和t处两个历史中记录的访问是相似的(即，重复在时间t早先记录的历史)，则确定T的对页面集H、t、n的利用率是高的。在一个实施例中，利用率被计算为最近重叠中的页面的重新使用百分比，或两个历史/时间段之间的页面访问行为的重叠量。
在一些实施例中，温暖测量了历史H、t、n中的多少页面在当前时间t'>t仍然在节点上是本地的。因此，在该示例中，线程的历史的温暖将历史与在节点上仍然是本地的页面集相关联。在一个实施例中，温暖被计算为仍然在节点上是本地的页面访问的百分比或比率。这指示在最近访问过的页面中，有多少页面仍然驻留在节点上或在节点上是本地的。作为一个示例，假设确定在最近过去的一段时间期间由节点上的客户线程访问的页面中的80％现在从该节点消失。然后，当前时间的温暖将被计算为20％。
基于也在其历史H、t、n中的T正访问的页面百分比的估计，在线程T当前正运行的节点n处更新利用率。然而，如本文中所描述的，例如，如果移除当前在T的历史中的页面，则在节点n上更新温暖(独立于T当前正在其上运行的节点)。对于每个线程T，温暖和利用率二者都是相对于本地节点n计算的，其中存储了T的历史H、t、n，因此计算温暖和利用率可能需要的仅有参数是客户线程ID(即，本地节点隐含在以下API中)和时间戳t。可以存储在每个线程的每个节点的不同时间间隔内记录的多于一个历史。在一些实施例中，时间戳t是除客户线程标识符之外还使用的API的部分。
温暖和利用率之间的一个示例差异如下：温暖将线程的历史与包含历史的当前节点上的页面集相关联，而利用率将线程的历史与线程在其正在其上运行的节点上的当前访问模式相关联。
以下是利用率和温暖函数的示例：
(int)utilization(guest_thread_id)
(int)warmth(guest_thread_id)。
在一个实施例中，如下跟踪利用率。一段代码(本文中被称为“平衡器”)周期性地擦除第二级页表条目，但是并不释放存储器。例如，虽然在页表中将对真实物理页面的引用清零，但是页面本身不会被去分配。下次请求页面时，将发生故障。然而，因为有意或蓄意地移除了引用，所以已知的是页面访问实际上原本将是一个命中(即，如果在一个页面上发生了停顿，针对该停顿，引用被故意清零，那么确定的是命中原本将为该页面以其他方式发生)。通过实行上述采样，可以统计地计数参考以获得利用率的近似值。如上所述，可以实行采样以引发停顿，该停顿指示是否原本将以其它方式发生页面的命中。在引发的停顿期间，可以获得客户线程和gpa身份，如上所述。
管理有关页面集的信息
如上所述，客户线程与客户物理页面地址指示的客户物理页面相关联。在一些实施例中，客户物理页面具有下述属性，即其地址在整个荚(pod)中是唯一的。因此，在一些实施例中，被消费和维护的管理数据是客户物理地址(gpa)。如上所述，客户线程由客户线程号(其是使用诸如CR3和FS-Base0之类的寄存器的唯一客户线程标识符)指示，并且因此在整个荚中也是唯一的。
出于各种目的，将在下面进一步详细描述其示例，具有有效维护页面集并且有效测试包含和排除的数据结构可能是有用的。可以被使用的在时间和空间两者上都有效的数据结构的一个示例是布隆过滤器(例如，其中信息被散列化到位图中)。例如，布隆过滤器可以被用来以紧凑的方式记录线程的页面访问历史，其中线程访问历史(无论是命中还是未命中)随时间的推移而更新。可以调谐布隆过滤器的长度。
在一些实施例中，该页面集随时间的推移而更新。在一个示例实施例中，使用允许这种情况的一个版本的基本布隆过滤器，诸如老化的布隆过滤器。在一个示例实施例中，使用具有两个活动缓冲器的老化布隆过滤器，其通过维护两个布隆过滤器使FIFO排序中的数据老化，其中一个布隆过滤器满负荷而另一个保持最新历史。
在一些实施例中，独立于特定版本的布隆过滤器或被用来保持页面集的其他数据结构，使用描述所需的操作的以下示例API(并且可以关于布隆过滤器来实行)：
/>
如本文中使用的，亲和性是指示线程与其当前正在其上运行的节点的亲和性的度量。如上所述，可以根据线程访问的历史记录来确定亲和性，其中在该组访问当中，确定来自特定节点的访问数量。在一些实施例中，跟踪相对少量的最近访问的页面，并且对于每个这样的页面，跟踪最近到达的页面来自的节点id(entifier)(如果它移动的话，或者否则是本地节点ID)。对于客户线程，如果多个这样的页面来自同一节点n，则断言该线程对n具有“亲和性”(即，如果线程正在从特定节点拉取页面，则该线程具有与该节点的亲和性)。例如，假设评估通过线程的最后100次访问。例如，如果它们中的90％(或任何其他阈值，视情况而定)来自不同节点，则亲和性函数返回该节点的标识符。否则，该函数返回本地节点的标识符。
在一些实施例中，前述示例阈值(100次访问和90％访问来自特定节点)是可以(例如，通过实验)进行调整的初始化参数。可能存在权衡。一个示例权衡是为该项保留的页面越多，在获得节点的页面集的亲和性的度量之前，可以在系统中观察到越多碎片。例如，对于给定的线程，如果节点0上有1000个页面，并且线程在节点1上，则可以等待1000个页面以决定与节点0存在亲和性，然而，不幸的是，线程可能在页面已经移动到节点1之后从节点1迁移到节点0。
以下是亲和性函数调用的示例，它将客户线程ID作为输入并且返回节点id：node_id＝affinity(guest_thread_id)；
职责(duty)
如果vcpu执行大量的客户指令而没有停顿，则可以确定vcpu是生产性的。
在vcpu迁移之后，vcpu可能需要使某个常驻页面的最小限度集是生产性的。例如，可以观察到在vcpu迁移之后，在vcpu变得是生产性的之前vcpu通常需要大约15-30个页面(例如，这可以在实验上观察)。在一些实施例中，vcpu具有停留在节点处的职责，直到其已经实行了至少阈值数量的页面访问为止。(可配置的)阈值被用作开始为线程构建工作集的初始机制。如在本文中的示例中使用的，这些页面被称为活动集。活动集中的线程需要通过其计算来进行的页面的示例包括：在堆栈顶部处的页面、具有该线程接下来需要执行的代码的页面等等。例如，设置该阈值来防止线程访问页面然后迁移到另一个节点。如果vcpu过于频繁地迁移，则实际上可能不会做出任何进步，因为它们可能没有机会使用它们所需的客户页面集来做出足够的客户进展，因此可能是非生产性的。
如在本文中的示例中使用的，整理集(groomed set)指代客户线程在某个时间段内频繁访问的页面集，在一些实施例中，其持续时间是可调谐的。对于给定的客户线程，可能遇到多个整理集。如本文中使用的，项职责被用来指示强制客户线程在节点上停留一些时间的策略因素，以帮助形成整理(工作)集。但是，职责本身可能不足以维护它已创建的整理集。
在一些实施例中，职责函数调用将客户线程标识符作为输入，并且返回指示职责的布尔值作为输出。例如，布尔值可以被用来指示客户线程是否已在节点处完成其职责。可以使用职责的一种方式是请求者侧决策和成本项。例如，当vcpu确定(例如，响应于针对非本地页面访问的停顿事件)是发送对存储器页面的请求还是迁移时，如果客户线程尚未完成其在节点的职责，那么这有助于迁移vcpu(以及通过扩展，迁移客户线程)的更高成本。
(bool)duty(guest_thread_id)
可以通过计算或计数线程自其到达节点以来已经实行了多少次访问，并且将访问数针对阈值进行比较来确定职责状态。如果满足或超过阈值，则职责已被完成或以其他方式满足。如果未满足阈值，则职责尚未完成。
存储器压力
在一些实施例中，确保总是有足够的空间来满足节点上的存储器需求。然而，取决于多少vcpu正在节点上运行和多少I/O正发生，可能需要通过将页面移动到其他节点来快速将页面从存储器逐出。在页面的逐出不能足够快发生的情况下，该节点上的存储器压力被认为处于临界状态。在某些情况下，这是一个要立即处理的紧急情况。关于逐出的进一步细节在下面结合内务处理进行描述。
//节点上的存储器临界是报告鉴于节点的能力节点上是否有过多页面：
(bool)memory_critical(node_id)
优度度量(Goodness Metric)
本文中描述的虚拟化系统的效率可以通过将客户线程与它们需要的页面集进行协调来改进(例如，基于工作集和线程的关联的确定，如上所述)。确定效率的一个示例方式是通过定义在本文中被称为“优度”度量的内容。优度度量是线程的函数，并且指示线程在节点上运行时的效率(其中线程可能在不同节点上具有不同的效率)。如本文中描述的，如果线程在运行时很少停顿，则该线程是“好的”。可以利用跟踪优度的各种方式，如下面将进一步详细描述的。然后可以将优度度量用来确定如何更好地处理停顿。例如，可以考虑线程的迁移以及它们可能对由线程使用的页面的工作集的影响。作为另一示例，可以在做出关于页面逐出、对转移请求的响应以及使用那些页面可能如何影响节点上的线程的决策时使用优度度量(例如，如下面的“资源迁移协商”中所述)。
计算优度度量的示例如下。通常，客户线程在客户中累积运行时间越多，在具有尽可能少的未命中的情况下，客户线程实行得越好(即，净客户运行时间越长，以及未命中越少就越好)。可以跨越超内核中的子系统均匀地使用的度量的一个示例是“净客户线程运行时间/未命中计数”，其中“净”在一些实施例中指代移除由于超内核所致的任何线程空闲时间。在一个示例实施例中，该时间恰好在运行线程的vcpu返回到客户之前累积，并且在停顿之后停止时间的累积。当vcpu返回到客户时可以记录时间戳，并且当它下一次停顿时，记录新的时间戳。然后可以将两个时间戳之间的差异添加到累积的净客户线程时间。这是在逐个线程的基础上实行的。如果分子或分母变得过大，则它们的值可以被除(例如，两者都除以2)，使得该比率保持相同。
在一些实施例中，跟踪等待I/O所花费的净线程时间。当客户线程为I/O停顿时，运行该线程的vcpu被放置在事件表中，如上所述。当I/O完成时，运行该线程的vcpu被从事件表中取出并且放置在TidalTree中，其最终将在该TidalTree中运行。线程将实行I/O，无论它们是在裸机(bare metal)上还是在本文中描述的超内核上运行。裸机上的I/O等待可能变成裸机上的客户线程的运行时间的部分，并且在一些实施例中，在超内核中完成相同的内容。在超内核中并入I/O等待作为客户线程的运行时间的部分的一种示例方式如下。记录何时将线程放置在事件表中的时间戳。当I/O稍后完成时，获取两个时间戳的差异并且将该差异添加到客户线程运行时间。然后将(在vcpu中运行的)线程放置在TidalTree中。
如下面将进一步详细描述的，可以在本文中描述的虚拟化系统的各种部分中使用优度度量，诸如用于成本函数(例如，当考虑迁移线程时，如果其优度度量过高，则可以做出不迁移线程的决定)、内务处理(例如，关于平衡器，当由于存储器临界条件而要逐出页面时，可以选择那些线程效率不高的页面)和TidalTree(例如，当尝试排队等候包含线程的vcpu以使其准备运行，并且发现该节点已经过载有已经排队等候准备运行的vcpu，可能会挑选最差或效率最低的线程以放置在根中，而不一定是准备运行的那个)。
下面是优度度量的两个示例实现方式，这两个示例都计算净客户线程运行时间与两个备选项之一的比率：
1.未命中的数量，以及
2.净主机运行时间(不包括客户)
上述两个示例都很容易计算以及进行廉价监控。一个例外可能是第二个可能包括I/O的等待时间，而第一个不包括。在一些实施例中，如果要通过与裸机(其包括I/O)进行比较的方式来比较，则在两种情况下都实行相同的I/O处理(两者都应该包括，或者两者都应该排除I/O等待时间)。以上描述了关于I/O等待时间的并入的示例细节。
出于说明性目的，使用以下示例表单的函数：
//如果线程t的优度大于t，则返回真，否则返回假
boolean isGood(guest_thread t,threshold t)
在一些实施例中，在使用第二替换方案时，净主机运行时间被用作优度度量的分母。
页面争用(page contention)
如在本文中的示例中描述的，当单独节点上的两个或更多个客户线程在相同的短时间段内需要相同的(一个或多个)页面时，发生页面争用。页面争用的一个指示是节点上有持续在同一页面上频繁停顿的客户线程。这可能是因为页面经常被另一个线程拉动，该线程在两个线程之间来回拨动(ping)。(高度)争用页面的示例是每次实行系统调用时就访问的页面。例如，在Linux操作系统中，客户操作系统频繁实行系统调用来更新包含计时器的页面。然而，由于Linux内核在本文中描述的虚拟化环境中跨群集以分布式方式操作，如果所有线程都试图用定时器更新页面，则可能发生页面的颠簸。这可能会对性能产生负面影响。
页面争用的结果可能导致通常需要的页面在节点之间来回移动，或者争用的客户线程与其所需的页面位于一处。虽然后者可能潜在地减少这些具体争用页面上的重新停顿，但是它可能具有副作用，例如导致许多客户线程/vcpu位于一处，或者这些线程所需的不同页面集的停顿大幅增加。如果在pcpu迁移到的节点中没有有效运行的足够的pcpu，则许多vcpu位于一处可能会给系统带来压力。如果争用的客户线程具有大的页面集，并且它们在具有任何或非常小的交集的情况下在不同节点上访问，则对页面的争用可能无法证明使争用的客户线程位于一处是正当的。在一些实施例中，如何解决页面争用的决策考虑了这样的问题。
下面是可以被调用以检测页面争用问题的函数的示例。如下所述，对于特定页面，函数或算法确定哪些客户线程需要特定页面以及需要的多久需要一次。例如，对于需要页面的客户线程，该函数计算线程在短时间段内(例如，最近的过去)访问页面(例如，在页面上停顿)的次数的计数。如果计数超过(可配置的)阈值(例如，五次)，则页面被标记为被争用(例如，可以设置页面的二进制或布尔标志)。这指示客户线程在计数器处于阈值时争用节点上的特定页面。
//函数page_contention使用散列函数数据结构并且
//它标识客户线程是否相比于最近的过去中的给定阈值已更多地要求同一页面//
//函数page_contention_list返回也在同一页面(gpa)上争用的其他客户线程(bool)page_contention(gpa，guest_thread_id)
list of guest thread ids＝page_contention_list(gpa)
在本文中描述的成本项当中，一些可以被用来判定在页面争用时要采取的行动，诸如以下：优度度量：可以在检测到页面争用时使用上述优度度量来识别是否存在需要解决的问题。例如，如果争用客户线程实行良好，则检测页面争用不需要任何特殊处理。页面争用可以被忽略，并且将继续做出决策，例如，利用处理任何停顿的通用成本函数(上面描述了优度度量的示例API)。
线程的频率：在一些实施例中，如果一个线程比其余线程更频繁得多地运行(即，它更频繁地访问页面)，则这指示很可能存在单个线程应用，或者例外利用单个线程的应用，也许是主线程。这在本文中被称为流行线程。
在一些实施例中，不会强制流行线程迁移以处理页面争用，除非该移动与其工作集的其存储器放置不矛盾。在一些实施例中，不强制由于页面争用所致的流行线程的迁移改善了性能。
以下示例函数基于访问频率返回指示客户线程频率的值：
//基于访问频率的客户线程的频率(int)guest_thread_frequency(guest_thread_id)
线程之间的共同利益(interest)的大小：当一组协作线程中的多个线程在应用中共享存储器时，可能发生页面争用。在某些用户并行化工作负载中可能观察到页面争用，并且可能会有更多页面争用，因为应用程序员在应用级别编写更精细的粒度的并行应用以处理并发性。例如，假设客户应用实行其自己的多线程，并且具有其自己的共享存储器。这样的应用的客户线程很可能具有大量的共同利益(即，线程访问的页面中的重叠)。例如，这与Unix中的一组过程形成对比，这些过程具有有限量的共同利益，因为它们在不同的地址空间中操作。高性能数据库还可以利用大的共享地址空间实行它们自己的多任务和多线程。应用的客户线程不应该分开，因为它们可能正在共同的存储器页面上工作。或者，例如，应用具有在其客户线程当中分布的工作，使得一个线程的结果可以被另一个线程使用。本文中描述的用于确定共同利益的技术可以在应用级别和/或操作系统级别实行。
如果客户线程具有共同的大量共享页面，则客户线程可以通过与以其它方式争用的线程位于一处来看到性能益处。然而，估计成对的客户线程之间的共同利益的大小可能并不足够。假设以下示例场景：线程A与线程B有很多共同利益，线程B与线程C有很多共同利益，但是线程A和线程C没有共同利益。如果A和C位于单独的节点上，则线程B将必须通过频繁地在节点之间迁移或者通过频繁移动许多通常需要的页面来与A和C共享其共同利益。在任一情况下，与其中A、B和C位于一处的解决方案(假定它们具有足够的pcpu来运行)相比，性能将受影响。下面是一个示例API，其估计(多个)客户线程之间的共同利益的大小(只要这些线程全部都在同一节点上本地运行)。
//估计客户线程与集合中的所有其他客户线程的共同利益。
//该集合可以用多种方式给出，例如争用、频繁或本地客户线程(int)common_interest(guest_thread_id,set of guest threads)
如本文中所述，共同利益是指示在节点上的客户线程之间共享的页面集的大小的度量(其可以指示页面访问模式中的相似性)。在一个示例中，共同利益的大小被确定如下。获得了客户线程的工作集和线程集。确定线程的工作集中的重叠/交叉。
例如，假设存在第一线程T1和第二线程T2。每个线程具有它们最近访问过的相应的页面的工作集，W1和W2。例如，如果W1和W2只有一个共同的页面，则T1和T2不具有很多共同利益。然而，如果W1和W2的交叉是大量页面，那么这两个线程具有大量共同利益。
可以通过由正计算其共同利益的线程来访问被用来记录最近访问的历史(命中和未命中)的数据结构(例如，布隆过滤器)来确定线程的工作集。如上所述，可以在停顿期间确定未命中(例如，使用CR3和FS-Base0寄存器)。可以通过实行采样来确定命中。例如，如上所述，执行一段代码，该代码实行页表的采样，并且使页表无效，但是不从存储器中删除它们。当已经删除了对于被禁用的页面的命中，但是在节点上仍观察到该命中时，将重新启用页表，并且记录命中。因此，可以经由采样来近似命中数。命中可以被记录在线程的(最近)历史中。如果物理处理器包括指示何时发生命中的硬件，则还可以获得该信息以记录是命中的页面访问。确定的命中和未命中可以被记录为线程的历史中的页面访问。
W1和W2(其是线程T1和T2的最近访问)可以使用与相应线程相对应的相应位数组来表示它们。对于给定的位数组，“1”的数量和位置与所访问的页面和大小两者成比例。位数组被“与”。例如，如果与的结果全为零，则两个线程之间没有共同利益。确定与之后的“1”的计数，从而指示两个线程之间的共同利益的大小。计数或“1”的数量例如被计算为汉明重量(hamming weight)。该汉明重量是T1与T2之间共同利益的估计。
因此，如该示例中描述的，通过实行“与”获得和比较对线程的访问的最近历史。如果使用布隆过滤器，则被用来生成过滤器的散列函数应该是一致的，以便相同的页面散列到布隆过滤器中的相同位置。由于gpa被散列化，可以提供这种一致性，这在集群中的所有节点上是全局唯一的。然后计算汉明重量，其中该值指示共同利益的水平。
可以计算给定客户线程与多个客户线程(其可以在相同或不同节点上)的共同利益。在一个实施例中，共同利益的大小被计算为关于客户线程集中的每个线程针对给定客户线程所确定的个体共同利益的总和(如上所述计算的)。例如，如果要计算T1关于T2、T3和T4的共同利益，则确定T1与T2、T1与T3以及T1与T4的成对共同利益并且将它们相加以确定T1与包括T2、T3和T4的集合的总体共同利益。
当估计或以其他方式确定客户线程对其他线程的集合的总体共同利益时，可以从求和中过滤或排除某些个体共同利益大小值。例如，如果两个线程之间的共同利益低于阈值(例如，汉明重量为小)，则过滤掉该值。作为一个示例，假设正在关于在节点上本地运行的100个其他线程评估特定的客户线程，并且对于100个线程中的每一个，共同利益是1。添加到一起，共同利益是100，这可以指示请求客户线程与节点上的其他线程之间的高度共同利益。然而，实际上，与每个线程仅有少量的共同利益。因此，当估计共同利益的总体大小时，可以过滤掉小于阈值的个体共同利益大小。
在一些实施例中，例如，当争用页面发生停顿时，按需评估共同利益。例如，如下面将进一步详细描述的，可以在成对资源迁移中计算或使用共同利益。因此，可以在停顿事件期间(例如，当设置页面争用标记时)根据需要计算共同利益。
在一些实施例中，(例如，在二维数组中)存储所计算的两个客户线程之间的共同利益的每个成对计算。在一些实施例中，共同利益计算与时间戳相关联。例如，如果每个停顿处都存在页面争用，则在每次停顿后共同利益可能不改变，并且每次停顿发生时都不需要计算共同利益。时间戳可以被用来确定何时最后一次计算共同利益，其中如果已经过去足够的时间量或时间量阈值，则重新计算它(即，如果最近已经最近计算了两个线程之间的共同利益，则不需在每个停顿时计算它)。
存储器状态：移动客户线程以处理页面争用可能导致将来移动多个页面。因此，知道为该线程创建整理集的位置可能对做出该决策有用。(例如，参见上面相关部分中的API)。
在一些实施例中，页面争用问题可能仅需要被解析为特殊情况(即，与本文中所述的停顿处理不同)，例如，如果它伤害性能(其可以由优度度量来表征)，并且在某些实施例中，为了解决页面争用问题，协商了存储器状态和与其他线程的关系。在某些情况下，没有理由拒绝位于一处的客户线程，如果通过这样做，它们在局部性方面获得附加的益处，并且它们不会在pcpu可用性方面给系统带来压力。
VIOP：页面争用的一个示例子情况是在客户线程在I/O操作期间与viop(虚拟输入/输出操作)争用。在一些实施例中，如果表示物理设备的viop不能移动，则争用的客户线程被移动到包含viop的节点并且只要I/O活动持续就停留在那里。在替换的实施例中，I/O操作是远程的，因为这可能比在不同节点上的viop与客户线程之间来回移动页面更具成本效益。
//如果共享页面的客户线程与viop之间存在争用，则返回真(bool)viop_contention(gpa,guest_thread_id,viop_thread)；
上述历史信息、度量、成本项等可以被存储为元数据。这样的信息也可以在节点之间转移，例如，如果线程在需要迁移的vcpu中运行的话。虚拟化环境中管理的客户页面的数量可能很多。线程数也可以很多，但是通常比页面数小得多。因此，处理或以其他方式处置稀疏且通常不完美的数据以有效地管理将线程与页面的工作集相关联的元数据。可以防止关联线程与页面的元数据大小上长得过大并且过于陈旧(因为运行特性可能以不可预测的方式改变)，其中元数据以考虑线程可以迁移的方式来实现，其中相关联的元数据也被迁移(元数据引用的页面也可以被移动)。在一个实施例中，利用老化布隆过滤器以紧凑表示来实现一些上述元数据。
如下面将进一步详细描述的，上面描述的元数据(其将线程与页面集相关联)可以被用作(例如，在加权的非线性多项式中的)因数以做出关于如何处理vcpu停顿的决策。在一些实施例中，当vcpu停顿时，它正在运行客户线程。如上所述，客户线程也可以在客户操作系统的控制下(而不是在超内核的控制下)在vcpu之间移动。超内核可以根据线程的访问模式做出决策，无论线程在哪个vcpu上运行。其他因素可以被用来确定vcpu停顿时要做什么。
在一些实施例中，在每线程的基础上存储针对线程的以上所记录的历史和确定的度量/因数。
图13D图示了被用来存储关于客户线程(在客户操作系统中运行的线程)的信息的表格的示例实施例。可以酌情使用其它类型的数据结构。
在该示例中，表1330包括在客户操作系统中运行的客户线程。挂断(hang off)每个客户线程是线程信息。在该示例中，每行(例如，行1332)对应于不同的线程，例如通过其唯一的对应FS-Base0寄存器值来标识。对于每个线程，记录对上述每线程元数据信息的引用。在该示例中，对于每个线程，温暖(1334)、利用率(1336)和共同利益(1338)被记录在表格中。由线程进行的页面访问的所记录的历史(使用诸如布隆过滤器之类的数据结构表示)也可以包括在表格中。其他成本项/度量也可以被存储在表格中。给定行(线程)中的单元格还可以包括指向单独信息块的链接或引用或指针。然后可以通过线程来索引该表格(例如，散列表)以获得每线程的信息。因此，通过如上所述标识客户线程和/或客户物理地址空间，可以管理诸如图13D的示例中所示的表格。因此，可以利用与vcpu相关联的信息来标记特定线程(在已假定了vcpu的身份的pcpu中运行)。在一些实施例中，线程元数据的表格被存储在RAM(随机存取存储器)中。
在一些实施例中，计算机系统中的每个节点具有线程和线程信息的表格。这有效地形成了在特定节点上运行的所有线程的表格。可以在节点之间转移关于线程的信息。
图13E是图示了用于将工作集与线程相关联的过程的实施例的流程图。在一些实施例中，由超内核执行过程1350。当接收到停顿事件的指示时，过程在1352处开始。在一些实施例中，停顿事件与非本地页面请求相关联，如上所述。在其他实施例中，响应于检测到线程上下文切换而触发停顿事件，如上所述。
在1354处，保存与停顿事件相关联的虚拟处理器的状态。这可以包括保存处理器状态的块，包括内部寄存器、程序计数器等，如上所述。
在1356处，至少部分地通过评估所保存的处理器状态来确定所引用的客户物理地址空间和客户线程标识符中的至少一个。在一个示例实施例中，获得处理器状态的已保存块中的CR3寄存器的值。CR3寄存器值对应于在虚拟处理器中运行的过程(客户线程)所引用的客户物理地址空间。在一些实施例中，通过访问所保存的处理器状态块的FS-Base0寄存器中的值来获得在虚拟处理器中运行的客户线程的标识符(其唯一地标识客户线程，因为不同的客户线程将具有不同的FS-Base0寄存器值)。
在1358处，至少部分地基于1356处的确定来记录历史信息，如上所述。例如，由所标识的线程访问的所标识的页面可以被记录到该线程的页面访问历史中。作为一个示例，使用诸如布隆过滤器之类的数据结构来存储该线程的页面访问历史。可以基于所记录的历史来确定各种度量和因数并且也进行存储(例如，温暖、利用率、共同利益、优度等)。
因此，使用上述技术，给定页面p，可以确定什么线程具有对p的强烈需求。而且，给定线程t，可以确定t强烈需要什么页面。然后可以基于这样的信息来实行各种处理，如下面将进一步详细描述的。
资源迁移协商如上所述，在一些实施例中，当VCPU需要非本地资源(例如，代表客户线程执行)时，它尝试计算若干已知策略的成本(例如，是否请求来自拥有该页面的节点的资源或者vcpu是否应该迁移到所有者节点)。一旦计算出这些成本，超内核代码就会基于成本多项式选择最低成本策略。
在上述示例中，描述了请求者侧的一系列成本多项式，其中在所请求资源的所有者侧可能存在最小决策或没有决策。除了由于不可移动设备的当前使用而被连线(wired)或锁定到节点的页面(例如，通过不能移动的诸如硬盘驱动器之类的物理设备的直接存储器访问)之外，页面通常被发送到上面示例中的请求者。
在某些情况下，所有者发送所请求的页面可能不是最佳的。例如，假设请求者节点上的vcpu请求一页面。然而，如果所有者节点上有三十个vcpu已经主动使用该页面，则将所请求的页面发送给请求者将不是最佳的，因为所请求的页面在所有者侧具有大量使用。替代地，对于所有者来说，在vcpu从请求者迁移到所有者的情况下，否认或拒绝或否决该请求将是最佳的。
在下面描述的示例实施例中，所有者还具有一系列成本多项式以选择如何判定怎么处理它从请求者接收到的请求(如果vcpu决定迁移，则不需要在所有者侧实行决策，因为没有要求)。所有者侧的多项式系列被用来确定拒绝请求或发送/迁移所请求的页面是否更具成本效益(相对于请求者侧的多项式，这些多项式被用来确定是请求页面还是迁移请求该页面的vcpu)。通过在请求者侧和所有者侧两者做出决策，可以做出关于如何处理请求的更好或经改进的决策。
在一些实施例中，请求者和所有者节点的成本多项式彼此独立，并且可以在没有另一个的情况下存在。
请求者和所有者的决策多项式的决策和成本项的示例如下。虽然下面描述的示例涉及对页面的请求，但是本文描述的技术可以被酌情不同地适配成适应任何其他类型的资源。
请求者侧决策和成本项
请求者侧决策
1.请求——要求将资源从所有者节点发送到请求者节点。
2.迁移——将运行客户线程的VCPU移动到所有者节点。
请求者侧成本项
1.所接收到的拒绝——在一些实施例中，该项指示正在请求刚刚接收到拒绝的页面。在一些实施例中，请求刚刚接收到拒绝的页面导致请求的极高成本。
2.线程效率——在一些实施例中，该项定义客户线程在该节点上已执行的程度。在一些实施例中，基于未命中数和线程运行时间的比较来测量线程效率(例如，当线程正在运行且没有未命中时)，其中与线程运行时间相比，未命中越少，线程的效率越高。在一些实施例中，客户线程在请求者节点上执行得越好，VCPU(以及在VCPU上运行的客户线程)的迁移成本越高。线程效率的一个示例度量是优度度量。
3.存储器不足——在一些实施例中，该项指示请求节点是否耗尽存储器。在一些实施例中，耗尽存储器的请求节点是请求资源的高成本。
所有者侧决策和成本项
所有者侧决策
1.发送——将页面发送到请求节点
2.拒绝——通知请求节点它应该做出新的决策。
所有者侧成本项
1.页面连线——在一些实施例中，该项指示该页面由非可移动设备使用，并且不能被移动。在一些实施例中，被连线的页面是发送资源的极高成本。页面是否由不可迁移的资源或设备使用可以由一组位指示。作为连线的页面的状态可以是瞬态的并且随时间的推移而改变(例如，当硬盘驱动器不再使用页面以进行直接存储器访问时)。
2.效率比较——在一些实施例中，该项指示请求者侧上的请求线程是否比使用所请求的页面的所有者节点上的任何线程运行得好得多。在一些实施例中，与使用所请求的页面的所有者节点上的任何线程相比，请求者侧上的请求的线程运行得越好，拒绝该请求的成本越高。
页面温暖——在一些实施例中，该项指示正被请求的页面是否由于最近的请求被移动到所有者节点以及是否在所有者节点上频繁地访问正被请求的页面。在一些实施例中，高值指示发送的高成本。
在一些实施例中，对于成本多项式，对每个项进行加权以表达该项多么重要。作为示例，可以对“所接收到的拒绝”成本项进行加权，使得无论其他成本项是什么，它都将反映出请求页面的成本比迁移到页面的成本要高得多(即，Request_Cost>Migrate_Cost)。同样地，“连线的页面”成本项可能会被加权，使得它将反映出发送成本高于拒绝成本(Send_Cost>Reject_Cost)。在一些实施例中，这反映了在所呈现的那些当中可能没有其他选择。否则，在一些实施例中，可以将权重设置成基于性能分析和调谐的值。
在一些实施例中，实行短路多项式评估，其中除了权重之外或代替权重使用短路控制机制。可以使用加权和短路机制两者。
用于请求页面的示例事务以下是用于请求页面的示例事务，其结合图14A-14E进行描述
示例初始配置
在以下示例中，假设以下场景，其结合图14A进行描述。
图14A图示了客户虚拟机的示例初始配置：
·荚中有2个节点(Node_1(1402)和Node_2(1404))(其中荚的示例是虚拟化系统，诸如图1的计算机系统100)。
·VCPU_1(1406)正在Node_1上运行Guest_Thread_1(1408)
·Page_1(1410)在Node_2上
·VCPU_2(1412)正在Node_2上运行Guest_Thread_2(1414)
·VCPU_3(1416)正在Node_2上运行Guest_Thread_3(1418)
·在此示例中，作为其执行的部分，Guest_Thread_1需要Page_1。这导致从客户(操作系统)退出并且到超内核中以满足请求。在该示例中，如上所述，VCPU_1(其正在运行Guest_Thread_1)调用一组函数(1420，见图14B中)以确定是否请求页面或迁移到当前具有该页面的节点(例如，通过评估上述请求者侧成本多项式)。在一些实施例中，该组函数被实现为具有公共应用编程接口(API)的函数指针的数组，该API返回被乘以权重的值以获得新值。将函数返回的所有值相加，并且乘以针对那些个体函数中的每一个函数的权重以获得值。然后针对迁移成本来获得最终多项式结果值，而针对请求成本来获得另一个多项式结果值。采用最低成本(即，最便宜)的方法。下面描述关于迁移成本和请求成本计算的其他示例。
示例阶段1
以下是结合图14B描述的用于请求页面的示例事务的第一阶段的示例，图14B从图14A的示例继续。
在该示例中，VCPU_1基于诸如上面列出的成本多项式在超内核中执行成本分析(请求者侧)。在该示例中，如在1420处所示，由于这是初始请求，因此“所接收到的拒绝”(RR)成本项为0。假设到目前为止，线程效率一直非常好，因此“线程效率”值与权重的组合为50。在该示例中，对“存储器不足”(OOM)的检查为0，因为此节点上有大量可用的存储器。这导致“请求”决策的成本为0，并且“迁移”决策的成本为50。因此，在该示例中，结果是从Node_2请求页面(因为请求的成本低于迁移的成本)。如果结果是迁移，则不进行请求。
在该示例中，VCPU_1为Page_1创建请求分组，并且在各种实施例中包括关于线程效率，该线程在(短暂的)过去多久请求该页面一次，以及请求类型(例如，读取/写入等)的信息。该信息经由例如互连的网络传输到Node_2。如下面将进一步详细描述的，当确定是拒绝请求还是发送所请求的页面时，所有者节点(Node_2)可以使用与请求一起传输的信息。与请求一起传输的信息的其他示例包括与Guest_Thread_1相对应的元数据信息，诸如温暖、利用率和共同利益，如上所述。还可以传输线程的记录的历史。例如，历史的数据结构(例如，布隆过滤器)表示可以与请求一起传输。以下将更详细地描述元数据信息的其他示例及它们在资源迁移协商中的使用。
在该示例中，此时，VCPU_1等待页面到达或等待消息从Node_2到达。
示例阶段2
以下是结合图14C描述的用于请求页面的示例事务的第二阶段的示例，图14C从图14B的示例继续。
在该示例中，Node_2从Node_1接收请求Page_1的分组。在一些实施例中，使用已经存储在Node_2上的信息作为超内核的正常操作的部分，Node_2基于例如上面列出的所有者侧成本项来执行成本分析(1422)。在该示例中，该分析的结果是要发送页面或者拒绝请求的决策。
出于说明性目的，在该示例中，假定所请求的页面未连线到非可移动的设备，并且其最近由Node_2上的线程Guest_Thread_2和Guest_Thread_3大量使用。
在该示例中，由于页面未被非可移动的设备主动使用，因此成本项“页面连线”返回0。在该示例中，无论什么权重，该项都是0。接下来，在该示例中，假设针对效率而言对线程Guest_Thread_2和Guest_Thread_3的分析产生公平的效率。在该示例中，这两个线程正在进行多次调用以得到资源，并且不如Guest_Thread_1高效。最后，在该示例中，计算此页面的“页面温暖”成本项。在该示例中，由于最近的过去已经为Node_2上的线程Guest_Thread_2和Guest_Thread_3多次访问该页面，因此这允许发送的高成本。
基于对这两个值的评估，确定了针对发送页面的值75和针对拒绝请求的值50。在该示例中，基于这些值，请求被拒绝(因为拒绝请求的成本低于发送页面的成本)。在一些实施例中，作为拒绝分组的部分来包括拒绝的原因，在该示例中，拒绝分组被往回发送到在Node_1上等待的VCPU_1。
示例阶段3
以下是用于请求页面的示例事务的第三阶段的示例，其是结合图14D进行描述的，图14D从图14C的示例继续。
在该示例中，拒绝分组将返回到Node_1，并且已经使VCPU_1准备运行，使得它可以运行Guest_Thread_1。在一些实施例中，重新进入到客户中使得在Page_1上再次发生停顿。该停顿导致从客户退出到超内核中，并且在一些实施例中，再次执行成本分析以确定如何解决Page_1访问的问题。然而，在该示例情况下，“所接收到的拒绝”成本项返回正值，并且利用该项的权重，请求和迁移决策的值最终会在阶段3中产生与阶段1不同的结果，做出将VCPU_1迁移到Node_2的决策(因为迁移的成本现在低于请求资源的新成本)。
如从请求者/所有者协商的上述3阶段示例可以看出的，如图14E的示例所示，该示例协商的最终结果(图14E从图14D的示例继续)是要使VCPU_1(正在运行Guest_Thread_1)从Node_1移动到Node_2以满足Page_1的请求。
在各种实施例中，可以添加不同的成本项以支持请求者决策(请求、迁移)，以及用以支持所有者决策(发送、拒绝)的成本项。将在下面进一步详细描述用来支持所有者决策的成本项的另外的示例。
图14F是图示了资源迁移协商的过程的实施例的流程图。在一些实施例中，过程1430由超内核(例如，接收对页面的请求的目标节点上的超内核，其中目标节点拥有所请求的页面)来执行。在该示例中，实行目标节点与发送请求的远程节点之间的成对资源迁移协商。该过程在1432处开始，此时接收到对资源的请求(例如，物理存储器的所需部分，诸如物理存储器的页面)。
例如，请求是由在第一节点(也被称为“请求者节点”或“发起者节点”，请求从该节点发起)上的pcpu中运行的vcpu做出的。进行请求的vcpu正在运行需要所请求的存储器页面的客户线程。例如，在执行客户线程时，虚拟处理器不能访问客户线程所需的页面(例如，因为它在发起者节点上不是本地可用的)。发生停顿事件，其中客户线程不能继续其处理，除非它能够访问所需的物理存储器页面。如上所述，发起者节点上的vcpu评估一组成本函数(例如，多项式)以确定适当的策略——是将其自身迁移到发起者节点以更靠近所需的存储器页面，还是发送对所需存储器页面的请求。在该示例中，vcpu已确定请求所需存储器页面的成本较低。因此，响应于发起节点上的客户线程在非本地页面请求上停顿，发起者节点发送请求并且在1402处由目标节点(其拥有所请求的页面)接收该请求。
所接收到的请求还包括元数据信息，其中至少一些将由目标节点用来确定是发送所请求的页面还是拒绝该请求。该请求包括正被请求的资源的标识符(例如，正被请求的物理存储器的页面的gpa)。被包括在请求中的元数据信息包括与需要所请求的存储器页面的客户线程相对应的每线程元数据。元数据信息可以被包括在经由互连的网络传输到所有者节点的请求分组中。
例如，如结合图14B的示例阶段1描述的，该请求可以包括关于线程效率、请求者节点上的客户线程在短暂的过去中多久请求所请求的页面一次，以及请求类型(例如，读取、写入等)的信息。
来自请求者节点的被包括在请求中的线程元数据信息的其他示例包括：诸如上述信息之类的元数据信息，包括温暖、利用率、优度/线程效率、亲和性、职责、页面争用(例如，通过标志指示)、共同利益的大小等。在请求者侧上进行请求的vcpu中访问客户线程的(最近)历史也可以被包括在请求中。如上所述，最近的访问历史可以被存储在布隆过滤器中，该布隆过滤器使用比特的数组来表示这样的信息。所发送的访问的历史可以包括在某个最近时段或时间窗口内的访问，或者例如，由在需要存储器页面的请求者侧上的客户线程做出的最近访问组(例如，最后10,000次访问，或任何适当数量的最近访问)。
在1434处，至少部分地基于所接收到的请求中包括的信息，确定是发送所请求的存储器部分还是拒绝该请求。可以通过评估一组成本函数/多项式来做出确定。
该组成本函数/多项式可以考虑来自请求者节点的请求中所包括的信息，以及作为超内核的正常操作的一部分已经存储在所有者节点上的信息。例如，在所有者节点处的成本分析可以基于上面列出的所有者侧成本项(例如，连线的页面、效率比较页面温暖等)。所有者侧成本项的另一个示例是已先前从请求者侧节点接收到的请求数。
当实行评估/确定策略的成本(即，发送页面或拒绝请求)时，来自请求者节点的请求中的一些线程元数据信息可以与存储在所有者节点上的信息直接比较/协商，而来自请求者节点的其他元数据信息不直接协商。
可以直接协商的请求中所包括的信息的示例包括在所有者节点上具有可以明确比较的直接配对/等效度量的信息。在各种实施例中，这样的可直接协商的信息包括温暖、利用率和共同利益的大小。
例如，可以将来自请求者侧的请求中包括的每线程信息针对所有者侧可访问/存储的本地节点级信息进行比较。所有者侧信息可以包括：关于所有者侧当前拥有的页面(包括所请求的页面)的信息。
作为一个示例，请求中包括的每线程温暖信息可以指示客户线程(当前在请求者侧)访问所请求的页面的最近时间。所有侧的温暖信息可以指示在所有侧节点处本地运行或执行的线程访问所请求的页面的最近时间。
作为另一示例，所有者侧利用率信息包括指示在所有侧上运行的在一段时间内访问所请求的页面的线程数以及以什么频率访问(例如，在最后十秒中，一个线程已访问所请求的页面一次等)的信息。该信息可以被用来确定页面是否在该节点上被高度利用(由任何线程)。如果所有者侧的所请求的页面利用率很高，则不应该放弃该页面，因为这会导致工作集的分解(以前已花费时间和努力来确保节点上的所有线程与它们需要的页面位于一处)。因此，分解已在所有者侧建立的该工作集的成本应该很高(并且不应该轻易放开所请求的页面)。
关于利用率，所有者侧还可以具有与在请求者侧运行的客户线程相对应的利用率信息。例如，客户线程可能先前已在所有者侧运行，并且关于线程行为的历史信息也可驻留在所有者节点上。如果在目标所有者节点上可得到这样的利用率信息，则可以将该信息与请求中的利用率信息进行比较。如果所有者侧利用率信息不可得，则不需要进行这样的比较(即，没有所有者节点上的客户线程的历史，因此没有与之协商的相关信息)。即使没有保证在所有者侧可能有什么信息，该请求仍然可以包括温暖/利用率信息，以防这样的信息在所有者侧可用/被存储在所有者侧以进行比较/协商。
被包括在来自请求者侧的请求中的可以在所有者侧成本分析中使用但未直接协商的信息的示例包括：为有关发起/请求者侧节点的请求vcpu中的客户线程所计算的信息，但是没有针对其的目标/所有者节点配对。在各种实施例中，不直接协商的此类信息包括：优度、亲和性、职责、页面争用和所记录的历史。例如，关于职责，其指示客户线程是否已完成其在节点上的职责(例如，自到达请求者节点以来的访问阈值数量，如上所述)，因为需要该页面的客户线程实际上并非在所有者节点上，因此不能确定客户线程关于所有者节点的职责。
作为另一示例，尽管请求者侧的客户线程没有在所有者侧运行，但是所有者侧可以使用被包括在请求中的客户线程的最近访问历史来确定客户线程在所有者侧本地运行时将如何表现或实行。
关于页面争用，如果请求包括已经发送的页面争用标记，则向所有者侧指示设法访问页面的请求者侧上的客户线程非常需要所请求的页面。如上所述，如果存在页面争用，则可以使用诸如优度度量、线程频率和共同利益之类的成本项来便于确定要采取什么动作。
例如，两个(或更多个)客户线程可能具有同一页面的页面争用。可以使用共同利益计算来确定两个线程是否应该在同一节点上共存。例如，争用客户线程(在请求者侧)与在请求者侧运行的其他客户线程的共同利益的大小可以与请求者侧处的客户线程与在所有者侧本地运行的客户线程所具有的共同利益的大小进行比较。可以使用上述技术(例如，通过求和并且确定汉明重量)来计算共同利益。
可以获得客户线程对请求者侧的线程的共同利益的大小(例如，动态计算，或者可以获得最近计算的共同利益)并且将其包括在请求中。
尽管客户线程没有在所有者侧运行，但是如果客户线程的访问模式历史被包括在请求中，则可以确定关于所有者侧的线程集的客户线程(在请求者侧运行)的共同利益。如上所述，通过在请求中发送访问模式历史，所有者侧可以确定如果客户线程在所有者侧本地运行其将如何表现或实行。例如，客户线程的访问模式由客户应用定义，并且独立于其上运行客户线程的节点。如果客户线程在所有者侧运行，则会进行相同的访问模式(取决于客户线程位置可能会有所不同的是什么访问是命中或者是未命中)。
因此，通过在请求中接收访问历史的线程模式，可以关于在所有者侧本地运行的线程来计算客户线程的共同利益。例如，如上所述，在所有者侧，对在所有者侧本地运行的每个客户线程的客户线程(在对页面做出请求的vcpu中)的共同利益的个体估计进行计算和一起求和(或者以另外的方式聚合)(其中如果共同利益的个体估计值低于阈值，则可以将其排除或从总和中过滤掉)。
在一些实施例中，响应于客户线程确定针对所请求的页面的页面争用，触发共同利益计算。如上所述，在一些实施例中，可以存储共同利益计算并且将其与指示何时最后估计共同利益的时间戳相关联。如果最近计算了适用于停顿(在请求者侧或者所有者侧，或两者)的共同利益值(例如，在阈值时间段内)，则估计共同利益(或估计的部分)不需要重新计算(因为它不太可能在该阈值时间段内发生变化)，其中重新使用它们的最近值(因此，可以避免重新计算，从而减少所使用的计算资源的量)。
如果感兴趣的客户线程(在做出请求的vcpu中)与所有者侧的线程(与请求者侧的线程相比)具有更大的共同利益，则这可能带来拒绝该请求的较低成本(或者发送该请求的较高成本)，这将导致客户线程迁移到所有者侧。
因此，除了确定客户线程是否在具有高频率的情况下对所请求页面具有高需求之外，可以在做出是发送所请求的页面还是拒绝请求的策略确定时利用客户线程之间的所访问页面中的重叠，以及与(例如，在最近的过去)在所有者节点上运行的线程的重叠。
如上所述，如果存在页面争用，则还可以使用优度度量/线程效率来确定所有者侧应该做出什么决策。例如，如果争用的客户线程在请求者侧表现不佳(例如，设置了页面争用标记并且在请求者侧节点上运行时客户线程的优度度量为低)，则应该拒绝页面请求，从而使线程迁移到所有者。
在一些实施例中，不可直接协商的信息可以被用来实行平局(tie)中断。例如，如果在实行具有请求者侧和所有者侧配对的度量的比较之后(例如，使用请求者侧信息和所有者侧存储的信息进行比较)，则确定平局，优度、亲和性等可以被用来实行平局打破。例如，如果线程具有高效率/优度或对请求者节点的亲和性，则所有者节点可以经由多项式来判定将页面发送到请求者节点。另一方面，如果线程在请求者节点上具有低亲和性或低优度/效率，则所有者节点可以判定拒绝该请求，并且使运行该线程的vcpu迁移到所有者节点。没有等效配对的因数也可以被用作多项式计算的部分(并且不仅仅在平局打破期间使用)。
所有者侧成本项的其他示例包括所请求的页面是否连线、效率比较和页面温暖，如上所述。例如，如果所请求的页面当前连线到所有者节点(例如，由磁盘访问以用于DMA)，则发送页面将具有非常高的成本，因为它将破坏在所有者侧已经发生的处理。
在一些实施例中，计算发送页面的成本和拒绝请求的成本。具有最低成本的动作(发送页面或拒绝请求)是被实行的动作。
在1436处，至少部分地基于该确定来提供响应。例如，如果在目标/所有者节点处做出决策来发送所请求的页面，则将该页面发送到发起/请求者节点。在一些实施例中，更新适当的数据结构和映射以指示物理存储器页面的新位置。例如，所有者可以记录已经将存储器页面发送给请求者，以便如果页面的现在的先前所有者接收到对页面的请求，它可以将该请求重定向到页面的当前所有者。
例如，如果请求被拒绝(即，请求成本低于发送页面的成本)，则将拒绝消息(例如，分组)往回发送到请求者/发起节点。在该示例中，响应于拒绝，请求者节点处的vcpu可以重新评估其成本函数集(例如，如结合图14D描述的示例阶段3中所描述的)。重新评估可以考虑新信息，诸如拒绝先前的请求，或者请求被拒绝的原因。可以计算用于迁移和/或请求页面的新的成本，其中请求者基于所确定的新的成本采取动作。
例如，如果请求者节点处的vcpu基于重新评估判定将其自身迁移到目标节点，则vcpu被迁移，如上所述。由于vcpu现在位于新节点上，因此还更新与在迁移的vcpu中运行的客户线程相关联的线程信息。例如，因为客户线程现在位于新节点上，所以更新每线程元数据信息，诸如温暖和利用率。
作为另一个示例，假设所有者侧拒绝了该请求，因为磁盘正在对所请求的页面实行直接存储器访问。这样的DMA往往是短暂的行为。基于该信息，请求者侧超内核可以确定再次请求页面，还等待做出请求(例如，除了确定是迁移还是请求之外，请求者多项式还可以被用来计算是否等待再次请求)。在一些实施例中，除了确定是发送还是拒绝请求之外，所有者侧超内核还可以判定另一个动作，诸如指示请求者再次尝试它们的请求。
因此，如上所述，在一些实施例中，在停顿时，客户线程向资源的所有者发送请求。在一些实施例中，该请求是可以具有相对合理数量的未使用空间的消息，该未使用空间可以被用来在节点之间传送附加的局部性信息(例如，上面关于客户线程的示例元数据信息)。如上所述，这种节点对之间的信息交换被用来在两个节点之间实行某种局部性协商。成对协商也可以代替维护全局一致状态信息的需要。通过成对协商，可以为所有客户线程收敛到足够好的状态。也可以利用1-n(一个节点到许多节点)类型的协商，但是可能更昂贵。关于这样的协商的细节在上面的“资源迁移协商”部分中进行了描述，其中还描述了在协商期间发送到其他节点的信息类型的示例。可以识别各种常见成本度量以用于比较。例如，可以针对两个节点之间的单个客户线程来比较对共同利益的大小的估计，并且提供的答案不是成本的值，而是其中客户线程可能会与其他客户线程具有更多共同利益的节点的标识符。如以上的示例所述，该信息可能有益于改进谈判的有效性。如上所述，在各种实施例中，在实行协商时发送优度度量、存储器状态和职责信息。可以利用共同利益和其他状态信息进一步扩展这样的信息。在请求消息中添加这样的信息，如上所述，该消息具有大量可用空间(例如，考虑到在没有这些附加协商参数的情况下它可以持有非常少的信息)。
超内核、事件表和TidalTree的其他细节和实施例
超内核线程
下面描述的示例将对FreeBSD线程进行各种引用。FreeBSD只是超内核可以与之合作的主机操作环境的一个示例(例如，其中超内核与FreeBSD一起工作，利用其服务，诸如用于I/O和线程管理的服务)，以及利用不同的主机操作环境或在不使用FreeBSD的情况下可以重新实现本文中描述的一些或所有FreeBSD特征。例如，可以编写超内核以完全不使用FreeBSD。作为一个示例，不是使用诸如FreeBSD之类的主机操作系统，而是可以构建多线程微内核以提供任何所需的功能。这将最小化对主机操作系统的依赖。为了最大化选项，FreeBSD与超内核之间的交互数可能会受到限制。例如，FreeBSD提供线程管理服务，其中一个方面是线程调度。FreeBSD调度器为线程提供基本抽象，可以将其分配给物理处理器(即，FreeBSD调度器是将线程分配到实际物理处理器上的实体)。通常，期望超内核来控制进行指派，而不是FreeBSD。可以减少超内核调度器与FreeBSD调度器之间的交互。下面描述关于超内核调度器的另外的细节。
主机可以在用户模式或内核模式下操作。由超内核实行的处理可以是主机的用户模式或内核模式。例如，可以在内核模式中实行超内核处理，以减少在FreeBSD中的用户模式与内核模式之间的上下文切换的数量。这减少了开销，诸如保存和存储寄存器、管理安全措施等。例如，事件表可以在超内核中以内核模式运行(即，在FreeBSD内核模式下运行)。
在自始至终所描述的示例实施例中，客户操作系统(以及在客户操作系统上运行的客户应用)认为它正在管理物理处理器，而实际上，客户操作系统正在管理由超内核提供的vcpu。客户操作系统还管理客户线程(其中客户操作系统具有自己的线程调度器)。这些客户线程在vcpu中运行(从客户操作系统的角度来看，这些vcpu是物理处理器)。当创建客户线程时，为它们指派名称(例如，作为位串的标识符)。如上所述，客户操作系统将客户线程的名称放置在特殊寄存器(例如，FS-Base0寄存器)中，该寄存器通过硬件架构对超内核可见。因此，可以标识客户线程(其中客户线程与FreeBSD线程处于不同的空间中)。当物理处理器假定(assume)运行客户线程的vcpu的身份时，将运行客户线程。
每个超内核实例中维护的三种示例类型的超内核线程包括：内务处理线程、I/O线程和vcpu线程。在一些实施例中，超内核线程的数量在初始化时是已知的，并且每个超内核实例可以在启动时在其上运行的节点上创建所有线程。
在一个示例实施例中，在超内核初始化时，在每个节点上运行的每个超内核实例创建FreeBSD线程以表示超内核中的每个vcpu和每个viop(虚拟输入/输出操作)。因此，在该示例实施例中，情况是每个vcpu和每个viop在每个节点上具有唯一的对应FreeBSD线程。辅助线程也可以由超内核实例创建。
vcpu线程是被用来表示vcpu的FreeBSD线程，并且运行与vcpu及其数据结构相关联的软件。如上所述，每个vcpu(其对于虚拟化系统是全局的并且可以存在于集群中的任何节点上)在每个节点上具有唯一的对应FreeBSD线程(本文中被称为代理(surrogate)vcpu线程)。例如，如果集群中存在四个节点，则每个vcpu都具有四个代理vcpu线程，四个节点各有一个。vcpu线程可以是空的或满的(即，分别是非活动或活动的)，其中在某时只有一个vcpu的vcpu线程运行或活动(vcpu的所有其他代理vcpu线程将为空或非活动的)，并且对于同一vcpu从来没有两个节点具有活动vcpu线程的情况，这将是客户操作系统的违规(其中一个vcpu不应该在两个不同的pcpu上运行)。vcpu在某时只能存在于一个节点上，其中只有一个vcpu线程正在为客户操作系统运行vcpu，而其他非活动的vcpu线程正在等待。因此，代理vcpu线程充当vcpu的代理者(proxy)，代表vcpu正运行的位置(节点)来处置处理(例如，vcpu线程在节点上运行vcpu，而vcpu本身可以在任何节点上运行)。在集群的节点上使用代理线程防止在例如vcpu迁移期间锁定和同步的需要。
vcpu线程将在客户操作系统中运行vcpu，或者vcpu线程没有在客户操作系统中运行vcpu，并且可能实行一些其他操作。例如，vcpu线程可以运行/执行超内核代码，直到指令它假定vcpu的身份的某个时间点。例如，在Intel架构中，vcpu线程可以执行VM进入指令，此时它正在客户vcpu中运行指令(并且不再在超内核中运行指令，直到例如VM退出发生为止)。例如，可能发生VM退出，因为当vcpu线程在客户操作系统中运行vcpu时，发生了页面错误。页面错误导致VM退出的发生。然后，vcpu线程将停止运行客户操作系统代码，并且将反而开始运行超内核代码。然后，对于vcpu并且使用超内核代码，vcpu线程将判定是迁移vcpu还是发送对页面的请求(例如，使用上述成本函数/多项式)。vcpu线程只为其对应的vcpu做出决策，而不是其他vcpu。
vcpu线程如何(在给定节点上)实行与vcpu相关的工作的一个示例如下。例如，假设要将vcpu迁移到目标节点。在迁移时，vcpu的处理器状态被显式保存到存储器中(例如，在创建继续部分时存储)。然后将该保存的存储器作为消息发送到目标节点(例如，通过被配置成处理这样的联网的网络线程)。然后发信号通知或通知目标节点上的代理/辅助线程以唤醒并且在目标节点上的pcpu上运行(可以调用FreeBSD将vcpu线程分配给pcpu，其中主机操作系统被用来将线程调度到物理处理器上)。现在在pcpu上运行的vcpu线程自己恢复到停顿的vcpu的状态(使用消息中包括的处理器状态)。实行VM进入。目标节点上的pcpu现在已采取vcpu的身份。然后，pcpu可以返回到客户操作系统，并且vcpu线程继续执行客户代码(而不是超内核代码)。从客户操作系统的角度来看，它没有观察到故障(超内核拦截了故障并且实行了vm退出/进入)。替代地，客户操作系统试图访问页面，并且在下一条指令中，它已经访问了该页面(其中客户操作系统不知道超内核实行的底层迁移)。如上所述，在集群的节点上使用代理线程防止了在vcpu迁移期间对锁定和同步的需要，其中在某时只运行vcpu的一个vcpu线程(vcpu的所有其他代理vcpu线程将为空，并且对于同一vcpu从来没有两个节点具有活动的vcpu线程的情况(即，在某时vcpu只可以存在于一个节点上)。
在该示例中，FreeBSD不控制vcpu线程的调度。替代地，vcpu线程在初始化时以等待状态开始。当超内核将信号发送到vcpu线程以唤醒时，vcpu线程仅发出信号来开始运行。例如，如下面将进一步详细描述的，超内核调度器和TidalTree绑定vcpu线程以使其处于活动状态(例如，唤醒给定节点上的vcpu的vcpu线程，以便vcpu可以开始在节点上运行)。创建这样的vcpu线程(其是数据结构)相对便宜，并且在它们等待时，不实行任何处理(或耗尽计算资源)。运行vcpu的vcpu线程是vcpu的表示，并且从超内核的角度来看是可调度的实体(其中，如下面将进一步详细描述的，vcpu线程可以在超内核的控制下用信号通知以唤醒或休眠)。在不同的时间，vcpu线程正在运行客户线程，但在其他时间，可能没有。例如，当vcpu正在节点上运行时，对应的vcpu线程正在运行vcpu(其正在运行客户线程)。当vcpu线程没有运行时(例如，vcpu没有在vcpu线程所在的节点上运行)，那么它可能正在等待或休眠。
如果vcpu正在运行(例如，不是继续部分)，那么它正在vcpu线程中运行。实行计算是在vcpu线程中完成的，其中，当vcpu正在运行客户线程时，是vcpu线程正在运行客户线程(其中客户线程由客户操作系统管理)。
当vcpu线程正在运行时，对应于客户所认为的物理处理器的寄存器状态实际上正在pcpu上运行(其中pcpu已经假定vcpu的身份，该vcpu具有一组处理器状态)。当vcpu线程正在运行时，正在使用虚拟处理器状态信息。例如，客户线程带有程序计数器、寄存器等。当客户线程在TidalTree中调度并且开始在vcpu上运行时，vcpu继承该程序计数器、寄存器等。当vcpu正在运行时，它是客户所认为的物理处理器的位对位(bit-for-bit)准确表示，并且事实上，vcpu正在物理处理器上运行(即，物理处理器通过承担vcpu的处理器状态来采取vcpu的身份)。在任何时候，当vcpu正在物理处理器上运行时，它与客户所认为的物理处理器精确匹配。当物理处理器绑定到虚拟处理器时，与虚拟处理器相关联的所有寄存器与关联于客户操作系统所认为的物理处理器的信息相同。如果操作系统在裸机上运行，则pcpu将具有与vcpu相同的状态。
当vcpu停顿时，vcpu在某些情况下将运行将原本在客户操作系统(OS)所认为的物理处理器中运行的客户线程，该物理处理器在本文中所描述的虚拟化系统/机器中实际上是虚拟处理器(即，vcpu)。在某些情况下，客户OS中的调度器(例如，可容纳其他客户操作系统的Linux)可能经常在某些基础上改变客户线程和vcpu的映射，从超内核的角度来看，这似乎是任意的(即，线程上下文切换，如上所述)。处理停顿时客户线程/vcpu关联并不改变(因为vcpu在其停顿时没有运行)。当客户操作系统在其所认为的物理处理器中复用客户线程时，超内核会注意到这一点。如上所述，超内核跟踪在vcpu中运行的线程的身份(例如，如通过处理器状态的FS-Base0寄存器所指示的，如上所述)并且注意到相关的线程转换事件。这部分是因为节点、存储器与线程之间的绑定/亲和性从客户线程立场发生，其中线程上下文切换可以重复发生，如上所述。例如，如上所述，当客户操作系统将客户线程切换到它认为的不同的物理处理器(但实际上从超内核角度来看是虚拟处理器)上时，寄存器(例如，FS-Base0寄存器)被更新，这对超内核是可见的。检测到线程上下文切换会导致停顿事件发生。
事件表(ET)的附加的细节和实施例
下面描述的是事件表的附加的细节和实施例，其可以被配置成考虑线程。事件表(在本文中被称为“ET”)和TidalTree(在本文中被称为“TT”)可以密切合作地进行操作。ET上的操作被设计成是简单、廉价、线程安全且通用的。如本文中所使用的，一起工作的ET和TT被称为“超内核调度器”。
在本文描述的示例中，ET是预期了期望要在将来发生的异步事件的数据结构。ET是在正在等待的事件已发生时可以咨询的数据结构，并且ET指示超内核由于事件发生而实行一组动作。
在一些实施例中，事件是抽象数据类型；该事件可能在该类型上具有有限但定义明确的操作集。
由于许多线程可能想要访问ET，因此实行围绕对ET的访问和更新的同步。例如，在ET中等待事件的线程可能是在vcpu中运行的客户线程，或者是等待从远程节点完成I/O操作或接收完成中断的viop线程。
除非线程已经在ET中等待，否则超内核线程不会调用FreeBSD调度器直接或间接等待。对于这一点的一个原因是超内核严格控制其资源的调度，以便做出适合超内核的决策。这些可能与FreeBSD调度策略冲突，或可能不与之冲突。在任一种情况下，目标都是最小化并且严格控制超内核/FreeBSD调度器交互。
在一些实施例中，超内核调度器和FreeBSD调度器是非干扰的。例如，移除了FreeBSD调度器的隐式调用(例如，cond_wait)。Viop可能会调用等待，因为底层I/O设备可能需要一些时间来完成其操作。在这种情况下，可以在事件表中表示vcpu，并且当事件发生时，vcpu转换到TidalTree(TT)。在一些实施例中，在FreeBSD域中实行I/O。因此，在一些实施例中，viop(而不是例如vcpu)调用cond_wait。
可能还有其他线程也与ET交互(例如，网络子系统中的线程)。以下是异步事件的示例列表：
·接收到征求的页面
·接收到未征求的页面
·接收到I/O完成通知
·接收到远程中断通知
·接收到远程或本地I/O操作
·接收到远程或本地的指令仿真请求
在该示例中，每个事件都具有状态。该状态可以是{预期，已发布，完成}之一。如本文中描述的，如果vcpu决定将其想要等待的事件放到ET中，但是尚未完成触发事件所需的所有工作，则事件是预期的。一旦触发事件的工作完成，它就会将状态从预期改成已发布。当事件引发时，状态将变为完成(并从ET中移除)。(在一些实施例中，不需要完成的状态，并且这里出于说明性目的进行描述，因为一旦事件已发生，它立即从事件表中移除。)ET中不应该存在完成的事件。一旦从ET中清除，任何等待事件的线程都会采用与该事件相对应的适当操作。
在一些实施例中，使用挂起位，其指示已经请求了页面。挂起位可以被实现为页面数据库中的页面上的位，其指示已经请求该页面(但是尚未接收到该页面)。注意的是，如果已请求页面，则事件表中存在与所请求的页面相对应的事件。因此，可能不需要挂起位和该事件两者。在任何一种情况下，该信息可以被用来确保节点不要求相同的页面两次(这可以防止请求页面的无限循环——例如，当节点发送页面时，它不知道页面是否由请求节点接收——挂起的位可能有助于保证这一点。
在某些情况下，页面到达事件可能在页面被正式请求之前(即，请求的形成仍在进行中)发生。在这种情况下，由到达触发的对ET的更新将看到事件尚未发布，但是它以预期状态处于事件表中。因此，在一些实施例中，在页面到达之后，事件状态被标记为完成，并且不进行实际请求。在这种情况下，当进行对ET的更新以将其标记为已发布时，更新反而将状态更改模拟为完成，就像事件已发生一样，并且通常情况下，事件被从事件表中移除。而且，如果页面在没有被征求的情况下到达，或者存在多个线程等待页面，则使在ET中等待它的任何线程准备运行。
要考虑的另一个示例问题如下。本文中描述的虚拟化系统中的不变量的一个示例是在同一节点上对于同一页面不存在重叠请求。这样做是为了确保针对动员资源的超内核搜索最终终止。这可以通过具有与完成未解决的请求相对应的第二事件来解决。因此，如果任何线程(原始线程或后续线程)在同一页面上停顿，则在满足第一个请求之前不发出另一个请求。
因此，在本文中描述的虚拟化系统中，每个节点上的每个vcpu和每个viop都具有相关联的FreeBSD线程。在一些实施例中，超内核处理vcpu线程，其与vcpu以1：1对应。vcpu具有相关联的FreeBSD线程(上面描述的vcpu线程)，例如，在超内核初始化时创建。viop也具有FreeBSD线程。vcpu或viop可以利用超内核线程id来标识，或者例如被表示为FreeBSD线程号。在一些实施例中，两者保持不相交，其中单独地维护将超内核vcpu或viop映射到FreeBSD线程的表格。这可以出于先前陈述的关于限制超内核和FreeBSD的相互依赖性的原因来完成。在一些实施例中，无论哪个FreeBSD线程负责从ET移除事件，都会导致等待的超内核线程被唤醒，例如，通过发信号通知其对应的FreeBSD线程。要注意的是，以这种方式这样做意味着在一些实施例中，不需要进一步考虑继续部分。在一些实施例中，计算的状态由FreeBSD线程号(或等效地，超内核定义的vcpu或viop号)表示。在该示例中，FreeBSD然后负责保存和恢复线程运行时间状态。
在一些实施例中，每个事件包含事件类型(其示例在上面列出)、事件状态以及在事件完成时要用信号通知的线程集。而且，如先前指示的，多个线程可能等待同一事件，在这种情况下，当事件引发时，等待事件的所有线程都被唤醒。这可以是下面描述的示例API的副产品，并且是本文中描述的示例ET实现方式的一部分。在一些实施例中，每个事件也与资源ID相关联(例如，客户物理页面的gpa)。在一些实施例中，对于事件表中的每个事件(由对应的资源ID标识)，事件表包括正在等待事件的vcpu列表(由它们全局唯一的vcpu标识符来标识的)。
在一些实施例中，因为事件表的API都被实现为安全的API(即，在一些互斥体下)，所以该集合可以被认为是Hoare式监视器。
//以安全的方式将事件插入事件表中。
//my_event可以是事件表的索引。
//如果事件已经在事件表中，
//将线程“t”添加到事件“e”发生时要唤醒的线程列表
my_event＝ts_insert_event(thread t,event e)；
//将所指示的事件的状态改为已发布
ts_change_event_status_to_posted(my_event e)；
//发信号通知等待它的所有线程继续进行，并且从事件表中移除e
ts_trigger_event(my_event e)；
TidalTree(TT)和调度的附加的细节和实施例
下面描述的是TidalTree(TT)和调度的附加的细节和实施例，在一些实施例中，其考虑了线程。
优化的TidalTree
图15A图示了TidalTree的替换实施例。在该示例中，TidalTree的替换实施例被称为“优化的TidalTree”，并且是上述TidalTree的优化或展平或缩小版本。
在TidalTree的以上示例实现方式中，TidalTree被实现为物理树，例如，深度为五的树(在包括超线程时)，其中树的每个节点/顶点具有准备运行的vcpu的工作队列。在TT的物理树实现方式中，每个第二级子树驻留在节点上，并且树中的每个顶点表示计算层次结构的物理部分。例如，叶对应于超线程。升一级表示将超线程加入到核心中。从其升一级表示包含其包含的所有核心的物理处理器。从其升一级表示包含其包含的所有处理器的主板。最后，升一级表示TidalPod(即，系统中的所有主板)。在使准备运行的vcpu排队时，会尝试将vcpu放置在上次运行的pcpu的队列中。如果该队列已满，则将搜索上一级的下一个队列，依此类推，直到可以将该vcpu添加到工作队列中为止。
在深度为五的TT的以上实现方式中，根的位置可以是任意的，但是在一些实施例中，可以在公知的节点上或者在启动时指定的节点上。根包含准备运行的TidalPod范围的没有在任何节点上的pcpu队列中排队的vcpu的队列。在一些实施例中，包含根队列的节点响应于入列根(enqueue-root)和出列根(dequeue-root)消息，但是根的位置可以独立于vcpu迁移策略；在一些实施例中，它可以是维护队列的节点。
在TidalTree结构的优化版本中，代替构建或实现物理树结构(如在深度为五的TT中)，优化的TidalTree被实现为与硬件配置中的每个物理处理器相对应的队列组(例如，图2的示例中的超线程)和全局可访问的队列，其中树的层次结构被拜访(visitation)次序替换。例如，被指派给超内核的每个pcpu都有一个队列。(例如，参见下面关于拆分调度器的讨论。)与每个物理处理器(例如，队列1502和1504)相对应的队列在本文中被称为“pcpu队列”，并且全局可访问的队列(1506)在本文中被称为“根”。不是以上深度为五的TidalTree的二维结构，使用一维结构来实现优化的TidalTree。在该示例实施例中，pcpu队列是深度为五的TidalTree的叶的示例，而全局可访问的队列是深度为五的TidalTree的根队列的示例。
与上面深度为五的TidalTree的示例实现方式相比，优化的TidalTree具有减少数量的工作队列。例如，如果存在向超内核指派的N个物理处理器，则优化的TidalTree中存在N+1个队列(N个物理处理器和一个全局可访问的根队列)，而深度为五的TT具有等于树中顶点的数量的多个节点。因此，减少了在优化的TT中要遍历/拜访的队列的数量。
因此，如上所述，在优化的TT的该示例实现方式中，优化的TT被实现为队列组，其中对于被指派给超内核的每个物理处理器存在一个队列，连同模仿树径(tree-walk)的遍历算法。在一个实施例中，pcpu队列被实现为准备运行的vcpu的先来先服务(FCFS)列表。在一些实施例中，预先确定搜索pcpu队列的次序以实现高速缓存亲和性。例如，使用与概念树的高速缓存级别相对应的搜索路径。高速缓存级别的知识被嵌入在物理处理器遍历算法中，而不是在维护树顶点上的多个队列，如深度为五的TT的以上实施例中所述。遍历次序可以在启动时固定并且对应于本文中描述的虚拟化系统的物理拓扑结构。
例如，假定在被指派给超内核的节点上存在p个物理处理器。在每个节点上，为FreeBSD保留了n个物理处理器，留下剩余的为超内核保留的p-n个物理处理器以在调度vcpu中使用。假定k个节点，则有k*(p-n)个vcpu要调度。
如上所述，每个pcpu具有一个准备运行的vcpu的相关联的FCFS列表。
如描述的，当vcpu停顿时，它被放置在节点的事件表中，等待事件发生。在这种状态下，vcpu无法迁移。当节点上发生事件(例如，通过某个pcpu pe触发)时，pe接收事件并且将等待该事件的所有vcpu入列到虚拟TidalTree中，然后继续进行先前进行的任何操作。(处理器pe可以是保留的FreeBSD处理器或者是保留的超内核处理器——无论哪个处理器处理事件，它都应该释放等待事件的适当的vcpu，并且将它们排队到TidalTree上)。
当pcpu pnew变可用时，它指派自己的工作，例如，通过搜索最合适的vcpu来运行。Pnew然后假定该vcpu的身份并且该vcpu开始运行。
关于将vcpu放置(“入列”)到TT上的过程的另外的细节和实施例(例如，在将其从ET取出之后)，以及将vcpu从TT出列到pcpu中的过程(例如，当匿名时pcpu正在寻找要实行的工作)在下面进一步详细描述。
将VCPU入列到TT上
如上所述，当从事件表中移除vcpu时(例如，因为vcpu正在等待的事件已经发生)，或者由于迁移的vcpu到达节点而使vcpu排队。在这两种情况下，如果可以找到适当的pcpu队列，则vcpu在该节点上的所选pcpu上排队(即，被放置在对应于特定pcpu的队列中)。
可以预先确定搜索pcpu队列的次序以实现高速缓存亲和性，其中，在一些实施例中，遍历次序符合高速缓存层次结构。在高速缓存层次结构或高速缓存的层次结构的一个示例中，相同核心上的两个超线程共享高速缓存数据、处理器芯片上的多个核心共享高速缓存数据，并且主板上的多个处理器共享高速缓存数据。
在一些实施例中，在可能的情况下避免在同一核心上的多个超线程的超额调度，因为核心上的多个超线程可能使用相同的处理器硬件，并且可能与彼此的执行冲突。因此，可能期望铺开超线程以防止这种执行冲突；然而，也可能期望尽可能多地利用高速缓存亲和性，从而导致两个可能冲突的目标。因此，在一些实施例中，针对正在使用的特定类型的处理器建立搜索次序(例如，在启动时)。
作为一个示例，当vcpu变为准备运行时，如下来实行针对在其上放置或入列准备运行的vcpu的队列的搜索。以开始选择的pcpu开始。作为一个示例，在与vcpu最后运行的pcpu相对应的队列上开始搜索。在一些实施例中，扩展每个vcpu的状态以记录最后节点和vcpu在其上运行的该最后节点上的pcpu。搜索可用的pcpu队列(以及通过扩展，pcpu)以vcpu在其上运行的最后的pcpu开始(假定vcpu最后一次运行，它在与当前所在的节点相同的节点上)。如果vcpu刚刚迁移(因此不能在其先前运行的pcpu上运行)，或刚刚启动，则可以任意选择要访问或拜访的第一个pcpu队列。如上所述，一个目标是不使核心过载。在一些实施例中，如果可能的话，搜索被偏向成在整个核心集上分布准备运行的vcpu，如下面将进一步详细描述的。
作为一个示例，搜索以所挑选的pcpu开始(即，如果可能的话vcpu最后在之上运行的物理处理器，如上所述)，以及搜索不在队列长度为零(即，队列为空)的同一核心上的高速缓存相关的pcpu。如果找不到一个，则尝试使vcpu在已经具有准备运行的vcpu的核心上排队。例如，搜索队列长度为一、然后为2、直到最大队列长度的队列。搜索的次序符合高速缓存层次结构。在一个示例中，首先尝试使vcpu入列在第一或开始的pcpu(队列)上，然后是其兄弟姐妹，然后是表兄弟，然后是第二表兄弟等等。在一个实施例中，pcpu p的兄弟姐妹指代与p共享相同核心的超线程。表兄弟处理器指代具有共同祖先的pcpu。表兄弟pcpu的示例是pcpu，它处于同一芯片的不同核心上。如果不能找到这样的pcpu，则被检查的下一个pcpu是在不同的芯片或插口上，但是在同一主板上(即，与p有物理连接)的pcpu。以这样的方式，隐式地，既找到了最温暖的高速缓存，而且vcpu被铺开在该节点上的可用pcpu上。
作为另一个示例，当vcpu变为准备运行时，如果可能并且如果对应的队列具有空的槽位(即，队列长度小于最大长度)的话，利用vcpu最后在其上运行的物理处理器(例如，超线程)开始搜索。否则，搜索将进行到下一个pcpu等等，直到节点上的所有可能性都耗尽为止。然后将vcpu放置在根上。
可以在启动时设置各种遍历次序。作为一个示例，在数字排序的核心列表中搜索下一个核心。如果vcpu可以放置在该核心上，则vcpu就放置在该核心上。这可能导致与vcpu最后在其上运行的pcpu共享一些相同的缓存行。如上所述，在一些实施例中，如果该核心上的兄弟姐妹超线程繁忙，则避免在同一核心上使用超线程。
图15B是图示了搜索pcpu队列的实施例的示图，在该pcpu队列上入列准备运行的vcpu。在所示的示例中，用于节点的主板具有两个芯片(例如，在主板上的两个插口中)，其中每个芯片具有两个核心，并且每个核心具有两个超线程(其他硬件配置可以是可能的)。因此，如该示例中所示，存在八个pcpu，在该示例中被标记为PCPU 0至PCPU 7。假设搜索从PCPU 0开始(1510)。如果vcpu不能放置在PCPU 0上，则在该示例中，在搜索中拜访的下一个pcpu队列是对应于PCPU 2的队列，该PCPU 2与PCPU 0在相同的芯片上但在不同的核心上。在该示例中，通过接下来拜访PCPU 2，如果PCPU 1繁忙，则可以避免芯片0的核心0的过载。此外，这试图在节点上铺开vcpu(例如，到其他核心上的pcpu)。
在该示例中，在对PCPU 2进行拜访之后的下一个PCPU队列是PCPU 1(例如，如果PCPU 1先前已繁忙，则在搜索中的此时可能不再繁忙，并且可以避免过载)。在其之后拜访的PCPU是PCPU 3，然后是PCPU 4(在该示例中移动到主板上的另一个芯片)，然后是PCPU 6，然后是PCPU 5，然后是PCPU 7。
在该示例中，定义上述排序的重复的公式为(+2-1+2)+1(+2-1+2)等等。作为“Kleene”或正则表达式模式，上面的由以下示例公式来定义：
[(+2-1+2)+1]*
如果在节点上找不到任何小于或等于最大队列长度的任何适当的pcpu队列，则vcpu在可用来运行在集群中的任何节点上的vcpu的全局可访问FCFS列表(根，如图15A中所描述的)上排队。不评估其他节点上的pcpu的队列，因为vcpu出于一原因在特定的节点上，例如，基于多项式策略的局部性——即，vcpu已迁移到具体节点，或者请求了要移动到其所在节点的页面。
在替换的实施例中，不是将vcpu放置在根上，而是将用于节点的表现最差的vcpu逐出并且撞(bump)到根队列上。然后将要排队的vcpu放置在pcpu队列上，从该pcpu队列中逐出表现最差的vcpu。
应该注意不要使节点上的pcpu过载；运行超内核线程的FreeBSD调度器队列应该保持尽可能短。在一些实施例中，可以使得准备运行(即，被放置在TT的pcpu队列和根队列上)的TidalTree线程的最大数量被指定为超内核初始化参数。
如果与虚拟化系统上的可用pcpu相比存在过多vcpu，则应该在荚的节点当中平衡CPU负载。可以通过跟踪准备运行的TidalTree中的vcpu总数来确定与可用的pcpu相比存在过多vcpu。可以假定的是可以容忍某种程度的过度承诺。该级别可以由启动时间参数建立。将在下面描述关于过度承诺的附加细节。如果节点的TidalTree(例如，与对于节点是本地的pcpu相对应的pcpu队列的集合)变得拥塞(即，将超过承诺级别)，则超内核可以实行例外动作，其中，如上所述，TidalTree选择准备运行的vcpu(例如，在节点上表现最差的vcpu)并且将其放置在特殊队列中——全局TT-根，如上所述，其中整个荚有一个根。
可以如下选择将从节点的pcpu队列中逐出并且撞到全局可访问的根队列上的vcpu。将被逐出的vcpu当前正在运行客户线程，因此具有相关联的优度度量。通过逐出此客户线程(通过逐出正在运行客户线程的vcpu)，这可能影响客户线程所需存储器的位置，以及可能与该客户线程有共同利益的其他客户线程的存储器的位置。在一些实施例中，为了判定要逐出哪个vcpu(通过将其放置到将来要被拔出的根)，考虑了诸如优度度量、存储器状态和共同利益之类的一组项(其示例在上面进行了描述)。例如，(在节点上的pcpu队列中)表现最差的vcpu(例如，如使用优度度量测量的)被逐出并且被放置在全局可访问的根队列上。
虽然保持pcpu繁忙和重新使用高速缓存行两者都可能是重要的，但是在一些实施例中，本文中描述的遍历算法断言了相对于重新使用高速缓存行偏向于保持pcpu繁忙，但是不会以利用过多超线程来使得核心过载为代价。
本文中描述的调度算法可以考虑线程身份。例如，使用本文中描述的调度算法，尝试将vcpu恢复到vcpu在其上运行的最后的pcpu上。vcpu正在运行客户线程，这在vcpu停顿时不会改变。当vcpu恢复时，它不仅将在可以识别的最有利的pcpu中恢复，而且在恢复vcpu时，线程被同时恢复到该线程在其上运行的最后的pcpu上。虽然这是启发式的(因为它可能无法观察L1、L2或L3缓存)，但是该方法是最佳的，其中线程被放置在其在其上运行的最后的pcpu上，或者被放置在可识别的不在同一核心上的最靠近的相关物上。
在一些实施例中，防止核心过载。例如，上述搜索可能被偏向于在整个核心集上分布vcpu。当空核心可用时，添加偏向以不将线程共同调度到超线程上(其中将vcpu放置在pcpu队列上将导致vcpu在对应的pcpu上运行，由此调度pcpu上的vcpu的运行)。例如，vcpu(以及通过扩展，在停顿的vcpu中运行的客户线程)可以被放置在其在其上运行的最后的pcpu上，或者被放置在不在同一个核心上的最靠近的相对物上。因此，以这种方式，如果已经在超线程上排队了vcpu，那么新的准备运行的vcpu不会被放置在共享相同核心的下一个超线程上。
在一些实施例中，遍历次序(队列的拜访次序)在启动时固定并且对应于系统的物理拓扑结构。
将VCPU从TT出列到PCPU中
在以下将vcpu从TT出列到pcpu中的示例中，假设客户操作系统跨越集群共同地运行。客户应用正在客户操作系统上运行。客户应用进而与客户线程相关联。vcpu(由vcpu在其上运行的节点上的其vcpu线程管理)运行客户线程。
vcpu存在于超内核的上下文中。在该示例中，vcpu在vcpu线程中运行。在该示例中，该vcpu线程实际上是FreeBSD线程，并且照此由FreeBSD作为FreeBSD线程进行管理，但是它也由超内核作为vcpu线程进行管理。在任何节点上，vcpu线程与vcpu之间存在1：1的对应关系。在一个示例实现方式中，在给定节点上，vcpu线程与FreeBSD线程之间存在1：1的对应关系。在某些情况下，超内核没有除了在其上超内核依赖于FreeBSD来提供的线程之外的其他线程。
假设虚拟化系统处于稳定状态。客户操作系统(例如，Linux)正在运行应用(例如，实行读取、写入、计算、执行指令、推进程序计数器等)。例如，已经(由客户操作系统)将与应用相关联的客户线程指派给已被指派给物理处理器的vcpu。
现在假设物理处理器代表客户线程执行指令并且尝试访问对物理处理器不可用的存储器页面(例如，存储器页面与物理处理器不在同一节点上)。例如，虚拟化硬件尝试将(例如，通过使用物理处理器在其上驻留的节点的第二级页表来实行动态地址转换)客户物理页面(其地址通过使用第一级页表获得，如上所述)转换到主机物理存储器中的真实物理存储器地址中。在该示例中，假设gpa没有条目(例如，第二级页表条目无效、清零等，并且gpa与节点上的真实物理页面之间没有映射)，并且物理处理器不能解析或引用对应的真实物理页面(该物理处理器已假设由在客户线程上工作的vcpu线程正在运行的vcpu的身份)。
因为虚拟化硬件(例如，Intel VT-x或AMD AMD-V)不能将gpa转换成真实物理地址，因此会自动生成中断。当硬件生成中断时，硬件访问中断表(操作系统的一部分)，该中断表包括中断发生时要调用的例程的地址。然后硬件引导到例程(例如，通过使用对应的地址)。例如，程序计数器(和任何其他寄存器状态)由硬件保存(例如，处理器状态被推到中断堆栈上)，并且新程序计数器被设置成在中断表中指定的例程。通过在实行中断例程之前保存处理器状态，物理处理器然后可以在从中断返回之后返回到其先前的状态(例如，在从中断返回之后，以相反的次序从中断栈中取出保存的状态，从而使处理器在中断发生后有效地跳转到下一个位置，使得客户操作系统将好像没有发生中断一样地继续)。
在该示例中，被调用的中断表/向量中包括的例程是超内核例程/代码。在一些实施例中，主机操作系统被配置成向超内核递送中断(例如，向超内核重新引导中断)，然后运行超内核代码。
上面描述了在超内核代码触发时被执行以处理中断的超内核代码的示例。例如，可以使用保存的处理器状态(例如，通过超内核代码，其具有对中断栈的可见性并且可以为继续部分获取保存的处理器状态的快照或副本)来创建继续部分。在处理了停顿事件之后，可以从继续部分恢复vcpu的状态(例如，当物理处理器假设或具有vcpu的身份时，它在vcpu中加载处理器状态)。
在该示例中，发生了停顿。停顿可以是可立即处理的某事，或者是将需要等待的某事。可以立即处理的停顿事件的示例是对计时器的请求。在获得定时器之后，处理停顿，并且可以不再考虑中断。
然而，如果停顿是例如页面停顿(由于非本地页面请求)，则停顿的处理将需要等待。例如，如上所述，评估一组多项式以确定处理停顿的策略。如上所述，要么做出请求页面的决策，要么做出将vcpu迁移到存储器页面在其上的节点的决策。
例如，假设确定要发送对页面的请求。在这种情况下，vcpu线程将不得不等待。然后，pcpu放置(在vcpu的vcpu线程表示中运行的客户线程的)线程ID和指向事件表中的继续部分的指针。存储在事件表中的其他信息包括被请求的以及vcpu(继续部分)等待的页面的标识符。
因此，如上所述，当vcpu停顿时，vcpu很可能已经在运行客户所认为的物理处理器的客户线程，但是从超内核的角度来看，实际上是虚拟处理器(即，vcpu)。客户操作系统(例如，Linux)中的调度器可以从超内核的角度来看，在某种任意基础上(即，线程上下文切换，如上所述)改变客户线程和vcpu的映射，但是客户线程/vcpu关联在停顿期间无法更改。如上所述，超内核可以通过检查处理器状态来跟踪在vcpu中运行的线程的身份，并且还可以在vcpu停顿时注意到线程转变事件。vcpu可以实行立即满足停顿所需的操作，或者vcpu可能需要发起动作使得客户可以之后完成操作，如关于上述事件表的讨论中所述。
例如，如果是后一种情况，一旦针对此停顿做出策略决策(迁移vcpu或发送页面请求)，并且已知这将导致延迟(即，无法立即处理停顿)，则如上所述，在事件表中放置一个条目，并且它正在等待的事件被标记为预期。在选择策略上的替换方案之后启动与停顿相对应的动作(例如，发起页面请求、发起I/O操作等)，并且vcpu线程(表示停顿的vcpu)在事件表中将状态设置成已发布。
现在，在vcpu线程将事件输入到事件表中之后，vcpu线程仍然在pcpu中运行，但是vcpu(技术上)不是(例如，vcpu线程正在运行超内核代码)。然后，已经运行vcpu线程的pcpu(其中pcpu现在是匿名处理器)可以直接或间接地实行有限量的内务处理(例如，平衡存储器使用)。在一些实施例中，vcpu线程发信号通知内务处理线程以唤醒和实行内务处理。替换地，vcpu线程可以自身实行内务处理，这减少了上下文切换的数量。
可以使用一种机制来限制内务处理线程可以做的工作量。可以通过需要客户完成的待完成工作量来参数化该机制。待完成工作量可以通过例如TidalTree中准备运行的vcpu的数量来表征。这可以在下面提供的示例中给出：例如，如果有许多准备运行的vcpu，则实行较少内务处理。另一方面，如果存在少量准备运行的vcpu，则可以实行更多内务处理。
//返回TT中准备运行的vcpu的数量
n＝runnable_vcpu()；
可能期望将实行FreeBSD工作的pcpu与代表客户操作系统来实行工作的pcpu隔离开来。例如，为FreeBSD保留少量物理处理器(例如，两个，其可以是启动时间参数)，而剩余部分可以用于超内核。这种责任划分在本文中被称为“调度器拆分”。如上所述，FreeBSD可以被用来处理线程休眠和唤醒，其中FreeBSD正在注意保存和恢复与给定节点上的vcpu线程相对应的FreeBSD线程的正确状态，该节点进而对vcpu响应。FreeBSD代表超内核自动地处理这些操作(并且可能是以高度优化的方式)。超内核迁移代码跨越节点和主机调度器边界来模拟这种行为。
以下是选择在现在的匿名物理处理器上下一个运行哪个vcpu的示例实现方式(即，选择准备运行的vcpu或将准备运行的vcpu从TT出列到物理处理器中)。
原本运行刚刚已被放置在事件表中的vcpu的vcpu线程实际上是在pcpu中运行的。在pcpu中运行的vcpu线程现在可以选择TidalTree中已经准备运行的等待的vcpu(如果有一个的话)。例如，以下出列算法由运行vcpu线程的pcpu(现在是匿名/可用的)来实行。
在对应于匿名物理处理器的pcpu队列处开始搜索在匿名物理处理器上运行的vcpu。类似于上述的入列/调度算法，向上遍历概念树以重新使用高速缓存行。如上所述，当vcpu被放置在TidalTree上时，尝试将vcpu放置在它们最后在其上运行的pcpu的队列上。现在的匿名pcpu(现在正在运行超内核代码，独立于任何vcpu线程)扫描其自己的队列，以搜索最近一直在pcpu上运行的准备运行的vcpu。新的匿名pcpu可能正在运行FreeBSD线程来实行扫描(当它正在搜索要假定的新的vcpu身份时)。在一些实施例中，匿名pcpu将尝试选择在由于高速缓存温暖而最后在其上运行的节点上的vcpu，其中选择最后一直在匿名pcpu上运行的vcpu允许重新使用最温暖的高速缓存。例如，每个物理处理器具有一个或多个级别的高速缓存，诸如转换后备缓冲器(TLB)和页面的高速缓存行条目。如果正在寻找的页面已经处于高速缓存中，则无需在存储器中搜索它。如果匿名pcpu的队列不具有准备运行的任何vcpu，则接下来着眼于其他队列，例如，遵循概念性高速缓存层次结构次序。
本文中描述的次序拜访的一个示例原因如下。假设多核处理器具有四个核心。每个核心具有高速缓存。如果存在两个多核处理器，每个具有四个核心，那么pcpu应该停留在它作为其一部分的多核处理器的队列上，因为它可能然后利用共享的高速缓存(即，更有利来使用具有物理局部性的核心，因为高速缓存行可以被重新使用的概率高于使用不同核心的队列的情况)。这在硬件配置中是真实的(其中硬件配置可以被描述为树结构或层次结构，如结合图2所描述的)。如果pcpu的节点上的所有pcpu队列都为空，则在一些实施例中，pcpu搜索在所有节点上对所有pcpu都是全局可访问的根队列。这有帮助平衡所有节点上的活动的效果。如果根队列也为空，则可以将pcpu配置成实行其他处理，例如内务处理。
在一些实施例中，相同核心上的两个超线程不是背对背调度的，因为两个超线程可以共享或使用相同的处理器硬件，从而可能导致彼此的执行冲突。
在选择准备运行的等待的vcpu时，pcpu采用所选vcpu的身份。例如，将在pcpu队列上已经等待最长时间的vcpu和/或最温暖的高速缓存亲和性从TidalTree中取出(例如，将第一vcpu从FCFS列表/队列中取出，该第一vcpu原本将是等待最长时间的vcpu)。成本函数也可以被用来确定哪个继续部分最适合指派给超线程。在一些实施例中，vcpu线程用信号通知所选的等待的vcpu来唤醒，然后将其自身置于休眠状态，从而等待它正在等待以完成的事件表中的事件。将所选vcpu的状态恢复到pcpu上。在该示例中，该休眠操作(其是主机调度器的隐式调用)允许FreeBSD调度器使用其中原本出于其他目的运行vcpu线程的pcpu(例如，内务处理线程或新唤醒的vcpu)。FreeBSD也可以选择使用不同的pcpu。上述信号/唤醒操作处于在该处超内核同步地调用FreeBSD调度器的显式点当中。
如果节点上没有准备运行的vcpu(即，针对节点上的队列的所有pcpu队列都为空)，则pcpu不应该让自己变为空闲。替代地，它应该从根中选择vcpu。通过在pcpu中运行的前一个vcpu停顿并且被放置在事件表上之后搜索工作，pcpu保持最大程度地繁忙(不是等待vcpu的停顿事件得到满足，而是pcpu搜索新的工作来实行)。如果根上没有vcpu，则在一个实施例中，循环上述的出列/vcpu选择算法，直到找到准备运行的vcpu(或者在本地节点的pcpu队列上，或者在全局可访问的根上)为止。在另一个实施例中，如果在另一个节点上存在准备运行的vcpu，则可以实行工作窃取，其中为vcpu查询另一个节点以运行，并且从节点“窃取”一个以在pcpu上运行。如果失败，可以暂停pcpu并且将其置于省电模式以节省电能，因为pcpu在荚/集群中的任何位置都找不到任何工作要做。在一些实施例中，pcpu的任务是实行内务处理以便保持最大程度地繁忙。
因此，如上所述，当pcpu变得可用时(即，因为vcpu被存储在事件表中、或者发生vcpu迁移、或者在启动或关闭时停止运行该vcpu)，将搜索pcpu队列以寻找最适当的vcpu以运行。如果节点完全没有准备运行的vcpu(即，与该节点相关联的pcpu队列为空)，则将第一vcpu从TT的全局根中拉离，并在该pcpu上恢复。
可以使用多种策略来选择应该从TidalTree中拉出或者出列或以其他方式选择的那个vcpu。在一些实施例中，成本函数被用来实现最高利益策略。要考虑的因素的示例包括：
1.应该避免饥饿。
2.局部性——可以咨询拉动它的节点上被拉出的客户线程的存储器状态。
3.如果尝试将vcpu负载压缩到最小可能数量的节点中，则可以从所涉及的节点中排除一些(对于vcpu负载)不必要的节点。
关于过度承诺的附加的细节
在一些实施例中，可用vcpu的每个pcpu队列的最大长度(即，准备运行的vcpu)是可调谐的。队列长度可以在启动时固定或动态可调谐。作为确定最大队列长度的一个示例，假设期望pcpu的数量等于vcpu的数量。最大队列长度可以被限制成vcpu的数量，这意味着系统中的所有vcpu都可以在单个pcpu上排队。在一些实施例中，为了鼓励在每个节点有p个pcpu的情况下均匀分布n节点的荚，每个pcpu的最大队列长度可以根据以下等式来确定：
可以实行实验来确定提供广泛工作负载的最佳性能的队列长度。
示例数据结构假设一个虚拟化系统，其中p个pcpu被指派给超内核，其中p个pcpu在n个节点当中分布。对应每个节点上的每个pcpu，有一个准备运行的vcpu队列。最初，该队列为空。在一些实施例中，每个pcpu还指定要以在启动时固定的模式搜索的下一个pcpu。在一些实施例中，搜索是循环搜索，其中在该示例中，搜索以两个参数开始：当前的pcpu和起始点。如果搜索返回到起始点，则已拜访了所有队列。
当物理处理器在每个节点上启动时，处理器寻找用以工作的vcpu。首先，物理处理器本地地(例如，在对于节点是本地的pcpu队列上)看，然后全局地(例如，对于全局可访问的“根”队列)看。在启动时应该注意不要使TidalTree的根过载。
内务处理函数如上所述，例如，假定上文提到的TidalTree机制就位，vcpu线程在将其vcpu放置在ET中之后可以直接或间接地调用各种内务处理函数。
在一些实施例中，可以经由平衡器线程(其可以被实现为另一个FreeBSD线程)来实行内务处理。在一个示例实施例中，平衡器线程是单个同步线程。平衡器线程跟踪存储器的量并且可以实行其他内务处理函数。平衡器线程还可以被用来实行上述采样。平衡器线程采取的动作可取决于利用率。在一个实施例中，利用率被分类成三个级别：低、高和临界。
平衡器可以由一个或多个pcpu异步运行。虽然pcpu是匿名的(即，在它已经摆脱先前的vcpu实体并且在假定新的pcpu的身份之前)，pcpu可实行一些内务处理。这允许内务处理工作负载在各种pcpu当中(而不仅仅是一个可能变得过载的线程)分布。
pcpu实行的内务处理工作量可能取决于各种因素而变化。作为一个示例，如上所述，由pcpu实行的内务处理工作量取决于排队等候运行的vcpu的总计数量。如果有大量vcpu准备运行，那么应该最小化内务处理量。如果排队等候的vcpu不多，那么pcpu可以实行更多内务处理。这允许pcpu保持做有用工作的最大程度的繁忙。
因此，允许平衡器做的增量工作量是有限的。例如，如果节点拥有大量准备运行的vcpu，则内务处理代码可以使用此信息(即，准备运行的vcpu的数量)并且相应地限制自身，以便pcpu可以例如被用作vcpu的容器。如上所述，平衡器被提供有指示TidalTree中有多少vcpu并且因此准备运行的信息。对于准备运行的低数量的vcpu，平衡器花费更多时间进行内务处理；对于较高的数字，平衡器花费更少的时间进行内务处理。
实行内务处理的一个示例是在临界存储器利用率水平(例如，存储器压力处于临界状态，如上所述)时摆脱或逐出页面。如上所述，可以实行存储器管理，这包括为每个页面跟踪哪些线程需要页面，并且还为每个线程跟踪它们需要哪些页面。可以基于这样的信息以及优度度量来确定要逐出哪个页面。例如，当评估页面以逐出时，可以确定需要该页面的每个线程的优度度量。例如，如果正在使用页面的线程表现良好，则该页面可能不应该被逐出，全部其他的是平等的。相反，可以逐出其线程表现不佳的页面。
在一些实施例中，以下调用都不返回状态(因为在某些情况下，不能对其进行任何操作)。在一些实施例中，调用被阻止以免调用将使FreeBSD调度器介入的任何代码(例如，诸如等待)，而不允许有机会从TidalTree中挑选要激活的下一个线程。
//在一些实施例中，在将VCPU发送到另一个节点之前调用该示例代码，
//允许内务处理代码实行内务处理，
//诸如提前移动页面。
//在该示例中，ts_load_hint是一个枚举，其指示下述内务处理代码
//为系统或者繁忙(并且限制自己)
//或者系统不繁忙。
void ts_housekeeping_on_vcpu_move(int vcpuid,void*arg,ts_load_hinthint)
//在一些实施例中，在将VCPU放置在事件表中之后调用它。
void ts_housekeeping_incremental(ts_load_hint hint)
以下定义了内务处理系统做决策时的一组示例案例，其中可以使用本文中描述的一个或多个成本项：
挑选何时采取行动的示例：内务处理可能不需要始终发生。如果内务处理函数“过度反应”，例如，通过发送过多页面，这可能可以引起存储器碎片。另一方面，如果内务处理的速度不够快，可能会由于存储器压力而强制过多vcpu迁移。在各种实施例中，使用存储器容量的估计、活动线程/vcpu的数量和IO的频率来便于判定何时采取行动以及将需要逐出多少页面。
挑选要逐出的页面的示例：在一些实施例中，平衡器在某个较短时间段内逐出一定数量的页面(例如，以避免过大的存储器压力)。可以使用来自诸如存储器状态、优度、共同利益之类的项的输入来逐出节点上与该节点上的客户线程相关的“最少”有用页面，或者例如，逐出对于在该节点上具有最少优度的客户线程有用的一组页面。可以实现各种替换方案。
挑选被逐出的目的地的示例：在一些实施例中，存储器不会比所需的展开更多。关于其他节点的容量的信息可以被用来帮助平衡器在没有其自身的平衡问题的节点上移动存储器。
图15C是图示了用于处理停顿事件的过程的实施例的流程图。在一些实施例中，过程1520由超内核实行。当接收到与在物理处理器中运行的虚拟处理器相关联的停顿事件的指示时，该过程在1522开始。停顿的一个示例是由于非本地的页面请求。
在1524，确定是否可以立即处理停顿事件。如果可以立即处理停顿事件，则在1526处立即处理它，并且过程1520结束(其中虚拟处理器在立即处理停顿之后继续在物理处理器中运行)。
如果不能立即处理停顿事件，则过程继续进行到1528，其中虚拟处理器被放置在事件表上。例如，假设可能不立即处理停顿事件，因为它是由非本地的页面访问所致。在该示例中，发送对页面的请求。然后将vcpu安置在事件表中(例如，其中其继续部分被放置在事件表中)，它在该事件表中等待所请求的页面。当事件发生或被满足时，则将虚拟处理器从事件表中取出并且放置或入列在TidalTree上(例如，图15A的Tidaltree 1500，使用图15E的过程1560)。将vcpu从事件表中取出并且将vcpu入列到TidalTree上有效地调度了pcpu上的vcpu的运行(因为当pcpu变为匿名并且搜索工作时，vcpu最终将由pcpu运行)。
原本一直运行虚拟处理器的物理处理器不再被视为运行vcpu，并且现在是匿名的。该过程继续进行到1530，其中选择准备运行的虚拟处理器以供物理处理器运行。用于选择准备运行的虚拟处理器的示例过程包括图9的过程900和图15D的过程1540。在1532，将所选虚拟处理器恢复到物理处理器上(其中物理处理器假定所选虚拟处理器的身份并且不再是匿名的)。
在一些实施例中，在步骤1530之前(例如，在pcpu变为匿名的时间与pcpu恢复后续vcpu身份的时间之间)，可以指派物理处理器来实行内务处理，如上所述。当内务处理工作完成时，过程继续进行到步骤1530。
图15D是图示了用于搜索准备运行的vcpu的过程的实施例的流程图。这可能包括将vcpu从TidalTree出列到物理处理器中。在一些实施例中，过程1540由超内核实行。在一些实施例中，过程1540被用来实现图15C的过程1520的过程步骤1530和1532。
当接收到停顿事件的指示时，过程在1542处开始。停顿事件与在节点上的物理处理器中运行的虚拟处理器相关联。该节点包括多个物理处理器。该节点被包括在节点的集群中，客户操作系统跨该节点的集群共同地运行。在一些实施例中，步骤1542是图15C的步骤1522的示例。
在1544，针对准备运行的虚拟处理器搜索与节点上的物理处理器相对应的队列组。与物理处理器相对应的队列组的示例是上面结合图15A描述的pcpu队列。以遵循概念高速缓存层次结构次序的方式来搜索该队列组。例如，可以根据预先确定的遍历算法来搜索该队列组，如上所述，其中队列的拜访次序对应于高速缓存亲和性并且模仿树径。在一些实施例中，被拜访和搜索的第一队列是与运行停顿的虚拟处理器并且现在是匿名的物理处理器相对应的队列。
如果在与节点上的物理处理器相对应的队列组中没有找到准备运行的虚拟处理器，则实行对集群中的多个节点全局可访问的根队列的搜索。
在1546，基于搜索来选择准备运行的虚拟处理器。例如，选择以遍历次序拜访的在第一非空队列前面的虚拟处理器(其中队列是FCFS)。在一些实施例中，基于成本函数来选择要运行的适当vcpu(例如，指派给匿名物理处理器)。例如，可以指派已经排队最长时间量的继续部分。将所选虚拟处理器指派给物理处理器(例如，恢复到物理处理器上，其中物理处理器采取所选虚拟处理器的身份)。
图15E是图示了用于在TidalTree上放置准备运行的vcpu的过程的实施例的流程图。这可能包括将vcpu入列到TidalTree上。在一些实施例中，过程1560由超内核实行。
当接收到虚拟处理器准备运行的指示时，过程在1562处开始。响应于虚拟处理器等待的事件已经发生，可以接收该指示。由于其等待的事件已经发生，将虚拟处理器从事件表中取出。作为一个示例，假设停顿的vcpu请求了页面。该页面已经到达，满足该停顿的vcpu正在等待的事件。例如，当页面到达时，访问事件表以确定什么vcpu在等待页面(由其资源标识符标识，该资源标识符诸如其客户物理地址)。虚拟处理器(以及等待页面的任何其他处理器)已准备运行。
在1564，至少部分地通过遍历与节点上的一组物理处理器相对应的队列组来确定在其上放置虚拟处理器的队列。例如，搜索如上所述被实现为队列的物理树的TidalTree。作为另一个示例，TidalTree被实现为准备运行的vcpu的一行或队列组，其中每个物理cpu(“pcpu”)有被指派给超内核的一个队列，其中物理TidalTree的层次结构被拜访次序替换(例如，优化的TidalTree，如结合图15A所描述的)。在一些实施例中，被拜访的第一队列对应于虚拟处理器在其上最后运行的物理处理器。如所描述的，可以扩展虚拟处理器的状态(例如，继续部分)以指示其在其上运行的最后的物理处理器。除非pcpu过载，否则vcpu被放置在队列上。如果第一队列已满或过载，则遍历将根据固定的遍历次序继续通过集合中的其他队列。在一些实施例中，遍历次序由系统拓扑结构定义。遍历次序模仿树径(例如，概念树的步行)。
如果物理处理器队列未满，则将虚拟处理器放置在物理处理器队列上(例如，在队列的末端或尾部，其中队列是FCFS)。因此，现在正在寻找工作的下一个pcpu具有一个附加的vcpu，用以看它可能会变成什么。所以，当下一个vcpu停顿时，原本运行停顿的vcpu的pcpu将挑选由于页面到达而被放置在队列中的下一个vcpu，它具有最温暖的高速缓存，并且成为新的vcpu(在某个时间点，因为队列上可能已经有其他vcpu)。如上所述，在一个实施例中，pcpu队列是FCFS或先进先出(FIFO)，使得被取出的vcpu将是已经在队列中达最长时间量的vcpu。也可以使用非FIFO策略。然后，计算机系统可以半自动地优化自身。
如果与节点的物理处理器相对应的所有队列已满(并且没有在其上放置准备运行的虚拟处理器的物理处理器队列)，则在一个实施例中，vcpu被放置在队列上(被称为“根”)，整个集群都可全局访问，任何pcpu都可以访问。作为一个示例，通过集群的节点之间的协议(例如，其中广播了根的内容)，使整个集群中的所有pcpu可全局访问根队列。
在上面，vcpu被放置在根上，因为所有其他队列在节点上已满。这可能不是最佳决策，因为它可能影响局部性。例如，在给定节点(例如，vcpu在其上最后运行的节点)上，vcpu可能已经表现非常好(例如，如通过优度度量所测量的)。在其他实施例中，不是将vcpu放置在根队列上，而是识别节点上的队列组中表现最差的vcpu并且将其从其物理处理器队列中逐出。作为一个示例，如上所述，根据优度度量来确定表现最差的vcpu。然后将被逐出的虚拟处理器放置在根、全局可访问的准备运行的虚拟处理器的队列上。然后将准备运行的虚拟处理器放置在物理处理器队列上(例如，在其末端)，移除从该物理处理器队列中被逐出的虚拟处理器(即，如果vcpu在节点上表现良好，则该节点上没有表现一样好的准备运行的vcpu应该将其在队列中的地点给予表现良好的vcpu)。因此，如上所述，当尝试将vcpu放置在队列中时，将其优度与其他vcpu的优度进行比较(比较停顿的vcpu中的线程的优度)。然后，将节点上按优度表现最差的vcpu移动到根。因此，如果正在放置的vcpu在节点上具有比节点队列中的另一个vcpu更好的局部性，则将表现较差的vcpu从节点移开并且将其放置在根队列中(即，在vcpu中运行的最差线程是被挑选以逐出到根队列的线程)。
在一些实施例中，当空核心可用时，遍历算法被偏向成不将线程(vcpu)共同调度到超线程(pcpu队列)上。
在一些实施例中，为了防止队列变得过长，实现了过载阈值(例如，队列上最多三个vcpu)。过载阈值可以是启动时间参数。例如，假设节点上的所有pcpu队列已满。例如，队列的长度可以加起来超过节点可以容纳的长度。例如，vcpu的数量可能是节点上的pcpu的两倍、三倍或十倍。过载阈值与优度度量一起迫使节点上表现最差的vcpu被逐出到根队列。这有益于使处理器展开并且防止群集/过载。这也导致创建与页面的局部性(即，构建工作集)。虚拟化系统上的负载也可以在需求驱动的基础上进行平衡。
虽然出于理解清晰的目的对前述实施例做出了比较详细的描述，但是本发明并不局限于所提供的细节。存在实现本发明的许多替换方式。所公开的实施例是说明性的而不是限制性的。

Claims (16)

1.一种计算机系统，其包括：
多个互连的计算节点，其中，每个计算节点包括多个物理处理器；
其中，响应于接收到与运行在物理处理器上的虚拟处理器相关联的停顿事件的指示，确定在所述虚拟处理器中运行的客户线程的标识符和由在所述虚拟处理器中运行的所述客户线程引用的客户物理地址；
其中，由所述客户线程引用的所述客户物理地址由所述客户线程记录在页面访问的历史中；以及
其中，至少部分地基于所述页面访问的历史中所包括的信息，通过将所述虚拟处理器迁移到由所述客户物理地址标识的物理存储器的页面在其上的节点来至少部分地处理所述停顿事件，其中所述停顿事件与非本地页面的访问相关联。
2.如权利要求1所述的计算机系统，其中在所述虚拟处理器中运行的所述客户线程的所述标识符是从FS-Base0寄存器获得的，所述FS-Base0寄存器处于与所述虚拟处理器相关联的虚拟处理器状态。
3.如权利要求1所述的计算机系统，其中所述客户物理地址是从CR3寄存器获得的，所述CR3寄存器处于与所述虚拟处理器相关联的虚拟处理器状态。
4.如权利要求1所述的计算机系统，其中所述停顿事件与线程上下文切换相关联。
5.如权利要求1所述的计算机系统，其中由所述客户线程所记录的页面访问的历史被存储在布隆过滤器中。
6.如权利要求1所述的计算机系统，其中至少部分地基于所记录的历史来确定对所述客户线程的温暖的度量，其中所述温暖的度量指示在所述所记录的历史中对计算节点是本地的页面的数量。
7.如权利要求1所述的计算机系统，其中至少部分地基于所记录的历史来确定所述客户线程的利用率的度量，其中所述利用率的度量指示在两个时期之间、所述客户线程的页面访问行为中的重叠量。
8.如权利要求1所述的计算机系统，其中确定当在所述多个互连的计算节点中的计算节点上运行时，所述客户线程的效率的度量。
9.一种用于计算机系统的方法，其包括：
响应于接收到与虚拟处理器相关联的停顿事件的指示，确定在所述虚拟处理器中运行的客户线程的标识符和由在所述虚拟处理器中运行的所述客户线程引用的客户物理地址，其中，所述虚拟处理器运行在物理处理器上，所述物理处理器被包括在多个互连的计算节点中，其中，每个计算节点包括多个物理处理器；
将由所述客户线程引用的所述客户物理地址由所述客户线程记录在页面访问的历史中；以及
至少部分地基于所述页面访问的历史中所包括的信息，通过将所述虚拟处理器迁移到由所述客户物理地址标识的物理存储器的页面在其上的节点来至少部分地处理所述停顿事件，其中所述停顿事件与非本地页面的访问相关联。
10.如权利要求9所述的方法，其中在所述虚拟处理器中运行的所述客户线程的所述标识符是从FS-Base0寄存器获得的，所述FS-Base0寄存器处于与所述虚拟处理器相关联的虚拟处理器状态。
11.如权利要求9所述的方法，其中从CR3寄存器获得所述客户物理地址，所述CR3寄存器处于与所述虚拟处理器相关联的虚拟处理器状态。
12.如权利要求9所述的方法，其中所述停顿事件与线程上下文切换相关联。
13.如权利要求9所述的方法，其中由所述客户线程所记录的页面访问的历史被存储在布隆过滤器中。
14.如权利要求9所述的方法，进一步包括：至少部分地基于所记录的历史来确定所述客户线程的温暖的度量，其中所述温暖的度量指示在所述所记录的历史中对计算节点是本地的页面的数量。
15.如权利要求9所述的方法，进一步包括：至少部分地基于所记录的历史来确定所述客户线程的利用率的度量，其中所述利用率的度量指示在两个时期之间、所述客户线程的页面访问行为中的重叠量。
16.如权利要求9所述的方法，进一步包括：当在所述计算节点上运行时，确定所述客户线程的效率的度量。
CN201780065872.8A 2016-08-29 2017-08-28 计算机系统及用于计算机系统的方法 Active CN109923523B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202310380629.2A CN116401058A (zh) 2016-08-29 2017-08-28 关联工作集和线程
CN202310380092.XA CN116401057A (zh) 2016-08-29 2017-08-28 关联工作集和线程

Applications Claiming Priority (17)

Application Number Priority Date Filing Date Title
US201662380896P 2016-08-29 2016-08-29
US62/380896 2016-08-29
US201762457609P 2017-02-10 2017-02-10
US62/457609 2017-02-10
US201762468856P 2017-03-08 2017-03-08
US62/468856 2017-03-08
US201762525544P 2017-06-27 2017-06-27
US201762525552P 2017-06-27 2017-06-27
US62/525544 2017-06-27
US62/525552 2017-06-27
US15/687,173 US10353736B2 (en) 2016-08-29 2017-08-25 Associating working sets and threads
US15/687154 2017-08-25
US15/687172 2017-08-25
US15/687,172 US10579421B2 (en) 2016-08-29 2017-08-25 Dynamic scheduling of virtual processors in a distributed system
US15/687,154 US10620992B2 (en) 2016-08-29 2017-08-25 Resource migration negotiation
US15/687173 2017-08-25
PCT/US2017/048903 WO2018044794A1 (en) 2016-08-29 2017-08-28 Associating working sets and threads

Related Child Applications (2)

Application Number Title Priority Date Filing Date
CN202310380629.2A Division CN116401058A (zh) 2016-08-29 2017-08-28 关联工作集和线程
CN202310380092.XA Division CN116401057A (zh) 2016-08-29 2017-08-28 关联工作集和线程

Publications (2)

Publication Number Publication Date
CN109923523A CN109923523A (zh) 2019-06-21
CN109923523B true CN109923523B (zh) 2023-08-25

Family

ID=61242403

Family Applications (3)

Application Number Title Priority Date Filing Date
CN201780065872.8A Active CN109923523B (zh) 2016-08-29 2017-08-28 计算机系统及用于计算机系统的方法
CN202310380629.2A Pending CN116401058A (zh) 2016-08-29 2017-08-28 关联工作集和线程
CN202310380092.XA Pending CN116401057A (zh) 2016-08-29 2017-08-28 关联工作集和线程

Family Applications After (2)

Application Number Title Priority Date Filing Date
CN202310380629.2A Pending CN116401058A (zh) 2016-08-29 2017-08-28 关联工作集和线程
CN202310380092.XA Pending CN116401057A (zh) 2016-08-29 2017-08-28 关联工作集和线程

Country Status (5)

Country Link
US (6) US10620992B2 (zh)
EP (1) EP3504618A4 (zh)
JP (1) JP6924820B2 (zh)
CN (3) CN109923523B (zh)
WO (1) WO2018044794A1 (zh)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9191435B2 (en) 2012-08-23 2015-11-17 TidalScale, Inc. Selective data migration or remapping of virtual processors to provide required data accessibility to processor cores
US10620992B2 (en) 2016-08-29 2020-04-14 TidalScale, Inc. Resource migration negotiation
US10579274B2 (en) 2017-06-27 2020-03-03 TidalScale, Inc. Hierarchical stalling strategies for handling stalling events in a virtualized environment
US10565102B2 (en) 2017-07-19 2020-02-18 International Business Machines Corporation Updating cache using two bloom filters
US10817347B2 (en) 2017-08-31 2020-10-27 TidalScale, Inc. Entanglement of pages and guest threads
CN109697115B (zh) * 2017-10-20 2023-06-06 伊姆西Ip控股有限责任公司 用于调度应用的方法、装置以及计算机可读介质
CN109697121B (zh) * 2017-10-20 2023-05-05 伊姆西Ip控股有限责任公司 用于向应用分配处理资源的方法、设备和计算机可读介质
CN109697120B (zh) * 2017-10-20 2023-06-27 伊姆西Ip控股有限责任公司 用于应用迁移的方法、电子设备
US10762137B1 (en) * 2017-11-15 2020-09-01 Amazon Technologies, Inc. Page table search engine
US10810133B1 (en) 2017-11-15 2020-10-20 Amazon Technologies, Inc. Address translation and address translation memory for storage class memory
US10754789B1 (en) 2017-11-15 2020-08-25 Amazon Technologies, Inc. Address translation for storage class memory in a system that includes virtual machines
US11409630B2 (en) * 2017-11-28 2022-08-09 Yale University Systems and methods of formal verification
CN109240802B (zh) * 2018-09-21 2022-02-18 北京百度网讯科技有限公司 请求处理方法和装置
US10977086B2 (en) * 2018-11-14 2021-04-13 Vmware, Inc. Workload placement and balancing within a containerized infrastructure
US11327814B2 (en) * 2018-11-28 2022-05-10 International Business Machines Corporation Semaphores for serverless computing
CN109918196B (zh) * 2019-01-23 2022-11-29 深圳壹账通智能科技有限公司 系统资源分配方法、装置、计算机设备和存储介质
US10970224B2 (en) 2019-06-28 2021-04-06 International Business Machines Corporation Operational context subspaces
US11176056B2 (en) 2019-06-28 2021-11-16 International Business Machines Corporation Private space control within a common address space
US11074195B2 (en) 2019-06-28 2021-07-27 International Business Machines Corporation Access to dynamic address translation across multiple spaces for operational context subspaces
US10891238B1 (en) 2019-06-28 2021-01-12 International Business Machines Corporation Dynamically joining and splitting dynamic address translation (DAT) tables based on operational context
CN110633076B (zh) * 2019-09-16 2021-05-04 杭州趣链科技有限公司 一种自动生成Solidity智能合约Java客户端程序的方法
CN110879746B (zh) * 2019-11-11 2023-03-31 西北工业大学 基于核间迁移的高安全关键任务调度方法
CN112000477B (zh) * 2020-08-21 2022-06-07 北京浪潮数据技术有限公司 一种pod中负载均衡的方法、装置、设备及介质
CN112202687B (zh) * 2020-12-03 2021-05-25 苏州浪潮智能科技有限公司 一种节点同步方法、装置、设备及存储介质
CN112734093B (zh) * 2020-12-30 2022-06-21 国网甘肃省电力公司电力科学研究院 基于计算机的制氢装置容量优化配置方法
US11755362B2 (en) 2021-06-11 2023-09-12 International Business Machines Corporation Techniques for handling escalation of interrupts in a data processing system
CN114500114B (zh) * 2022-04-14 2022-07-12 之江实验室 一种网络操作系统中应用的拟态数据库交互方法和装置
CN115061962B (zh) * 2022-04-28 2023-07-14 苏州浪潮智能科技有限公司 一种外设传输速率管理的方法、系统、存储介质及设备
CN116755891B (zh) * 2023-08-21 2023-10-20 成都中科合迅科技有限公司 基于多线程的事件队列处理方法和系统
CN117851107A (zh) * 2024-03-08 2024-04-09 中科鉴芯(北京)科技有限责任公司 可动态扩容的分布式自动测试向量生成方法、装置及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5230069A (en) * 1990-10-02 1993-07-20 International Business Machines Corporation Apparatus and method for providing private and shared access to host address and data spaces by guest programs in a virtual machine computer system
US6016542A (en) * 1997-12-31 2000-01-18 Intel Corporation Detecting long latency pipeline stalls for thread switching
US6807616B1 (en) * 2001-08-09 2004-10-19 Advanced Micro Devices, Inc. Memory address checking in a proccesor that support both a segmented and a unsegmented address space
JP2013135318A (ja) * 2011-12-26 2013-07-08 Canon Inc 画像処理装置、システム、制御方法、及びプログラム
US8752058B1 (en) * 2010-05-11 2014-06-10 Vmware, Inc. Implicit co-scheduling of CPUs
CN103885838A (zh) * 2014-03-27 2014-06-25 北京大学 一种获取虚拟机内存工作集的方法及内存优化分配方法
CN105393255A (zh) * 2013-07-05 2016-03-09 比特梵德知识产权管理有限公司 用于虚拟机中的恶意软件检测的过程评估

Family Cites Families (110)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5109486A (en) 1989-01-06 1992-04-28 Motorola, Inc. Distributed computer system with network and resource status monitoring
US5745778A (en) 1994-01-26 1998-04-28 Data General Corporation Apparatus and method for improved CPU affinity in a multiprocessor system
US6105053A (en) 1995-06-23 2000-08-15 Emc Corporation Operating system for a non-uniform memory access multiprocessor system
US6601083B1 (en) 1996-08-29 2003-07-29 Frederick John Reznak Multitasking data processing system and method of controlling allocation of a shared resource
US6658447B2 (en) 1997-07-08 2003-12-02 Intel Corporation Priority based simultaneous multi-threading
US5991893A (en) 1997-08-29 1999-11-23 Hewlett-Packard Company Virtually reliable shared memory
US6247109B1 (en) 1998-06-10 2001-06-12 Compaq Computer Corp. Dynamically assigning CPUs to different partitions each having an operation system instance in a shared memory space
US6266745B1 (en) 1998-09-04 2001-07-24 International Business Machines Corporation Method and system in a distributed shared-memory data processing system for determining utilization of nodes by each executed thread
US6336170B1 (en) 1998-10-13 2002-01-01 International Business Machines Corporation Method and system in a distributed shared-memory data processing system for determining utilization of shared-memory included within nodes by a designated application
US6748593B1 (en) 2000-02-17 2004-06-08 International Business Machines Corporation Apparatus and method for starvation load balancing using a global run queue in a multiple run queue system
US6823472B1 (en) 2000-05-11 2004-11-23 Lsi Logic Corporation Shared resource manager for multiprocessor computer system
US6625709B2 (en) 2000-10-30 2003-09-23 Microsoft Corporation Fair share dynamic resource allocation scheme with a safety buffer
JP2002202959A (ja) 2000-12-28 2002-07-19 Hitachi Ltd 動的な資源分配をする仮想計算機システム
US7797375B2 (en) 2001-05-07 2010-09-14 International Business Machines Corporat System and method for responding to resource requests in distributed computer networks
US6968398B2 (en) 2001-08-15 2005-11-22 International Business Machines Corporation Method of virtualizing I/O resources in a computer system
US7308498B1 (en) 2003-02-13 2007-12-11 Microsoft Corporation System and method for automating a request for access to a restricted computer accessible resource
US7451459B2 (en) 2003-05-05 2008-11-11 Microsoft Corporation Systems, methods, and apparatus for indicating processor hierarchical topology
US20040249947A1 (en) 2003-05-22 2004-12-09 Hewlett-Packard Development Company, L.P. Concurrent cluster environment
US20050015430A1 (en) 2003-06-25 2005-01-20 Rothman Michael A. OS agnostic resource sharing across multiple computing platforms
US9020801B2 (en) 2003-08-11 2015-04-28 Scalemp Inc. Cluster-based operating system-agnostic virtual computing system
US20050044301A1 (en) 2003-08-20 2005-02-24 Vasilevsky Alexander David Method and apparatus for providing virtual computing services
US8776050B2 (en) 2003-08-20 2014-07-08 Oracle International Corporation Distributed virtual machine monitor for managing multiple virtual resources across multiple physical nodes
US7380039B2 (en) * 2003-12-30 2008-05-27 3Tera, Inc. Apparatus, method and system for aggregrating computing resources
US8346909B2 (en) 2004-01-22 2013-01-01 International Business Machines Corporation Method for supporting transaction and parallel application workloads across multiple domains based on service level agreements
US7222221B1 (en) 2004-02-06 2007-05-22 Vmware, Inc. Maintaining coherency of derived data in a computer system
US8533716B2 (en) 2004-03-31 2013-09-10 Synopsys, Inc. Resource management in a multicore architecture
WO2005114959A1 (en) 2004-05-18 2005-12-01 British Telecommunications Public Limited Company Peer-to-peer networks
US20060037017A1 (en) 2004-08-12 2006-02-16 International Business Machines Corporation System, apparatus and method of reducing adverse performance impact due to migration of processes from one CPU to another
US7610681B2 (en) * 2004-09-29 2009-11-03 Ged Integrated Solutions, Inc. Window component stock indexing
US7328371B1 (en) 2004-10-15 2008-02-05 Advanced Micro Devices, Inc. Core redundancy in a chip multiprocessor for highly reliable systems
GB2419701A (en) 2004-10-29 2006-05-03 Hewlett Packard Development Co Virtual overlay infrastructure with dynamic control of mapping
US8621458B2 (en) 2004-12-21 2013-12-31 Microsoft Corporation Systems and methods for exposing processor topology for virtual machines
US9753754B2 (en) 2004-12-22 2017-09-05 Microsoft Technology Licensing, Llc Enforcing deterministic execution of threads of guest operating systems running in a virtual machine hosted on a multiprocessor machine
US7886126B2 (en) * 2005-01-14 2011-02-08 Intel Corporation Extended paging tables to map guest physical memory addresses from virtual memory page tables to host physical memory addresses in a virtual machine system
US20060242389A1 (en) 2005-04-21 2006-10-26 International Business Machines Corporation Job level control of simultaneous multi-threading functionality in a processor
US7596654B1 (en) 2006-01-26 2009-09-29 Symantec Operating Corporation Virtual machine spanning multiple computers
US20070226795A1 (en) 2006-02-09 2007-09-27 Texas Instruments Incorporated Virtual cores and hardware-supported hypervisor integrated circuits, systems, methods and processes of manufacture
US7802073B1 (en) 2006-03-29 2010-09-21 Oracle America, Inc. Virtual core management
GB0607294D0 (en) 2006-04-11 2006-05-24 Nokia Corp A node
US7783788B1 (en) 2006-04-28 2010-08-24 Huawei Technologies Co., Ltd. Virtual input/output server
US7865895B2 (en) 2006-05-18 2011-01-04 International Business Machines Corporation Heuristic based affinity dispatching for shared processor partition dispatching
US7752417B2 (en) 2006-06-05 2010-07-06 Oracle America, Inc. Dynamic selection of memory virtualization techniques
US7987464B2 (en) 2006-07-25 2011-07-26 International Business Machines Corporation Logical partitioning and virtualization in a heterogeneous architecture
US7844709B2 (en) 2006-09-20 2010-11-30 International Business Machines Corporation Method and apparatus for managing central processing unit resources of a logically partitioned computing environment without shared memory access
US8261345B2 (en) 2006-10-23 2012-09-04 Endeavors Technologies, Inc. Rule-based application access management
US8650296B1 (en) 2006-10-31 2014-02-11 Hewlett-Packard Development Company, L.P. Workload reallocation involving inter-server transfer of software license rights and intra-server transfer of hardware resources
US7913055B2 (en) * 2006-11-04 2011-03-22 Virident Systems Inc. Seamless application access to hybrid main memory
US7613882B1 (en) 2007-01-29 2009-11-03 3 Leaf Systems Fast invalidation for cache coherency in distributed shared memory system
US7694054B2 (en) 2007-04-26 2010-04-06 Microsoft Corporation Governing access to a computing resource
US7715400B1 (en) 2007-04-26 2010-05-11 3 Leaf Networks Node identification for distributed shared memory system
US20110004732A1 (en) 2007-06-06 2011-01-06 3Leaf Networks, Inc. DMA in Distributed Shared Memory System
US8365184B2 (en) 2007-08-31 2013-01-29 Apple Inc. Multi-core resource utilization planning
US8819675B2 (en) 2007-11-28 2014-08-26 Hitachi, Ltd. Virtual machine monitor and multiprocessor system
US7782869B1 (en) 2007-11-29 2010-08-24 Huawei Technologies Co., Ltd. Network traffic control for virtual device interfaces
US7711789B1 (en) 2007-12-07 2010-05-04 3 Leaf Systems, Inc. Quality of service in virtual computing environments
EP2071470B1 (en) 2007-12-11 2010-10-20 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Method and device for priority generation in multiprocessor apparatus
US20110004729A1 (en) 2007-12-19 2011-01-06 3Leaf Systems, Inc. Block Caching for Cache-Coherent Distributed Shared Memory
US8645965B2 (en) 2007-12-31 2014-02-04 Intel Corporation Supporting metered clients with manycore through time-limited partitioning
US8099541B2 (en) 2008-01-22 2012-01-17 Globalfoundries Inc. Minivisor entry point in virtual machine monitor address space
US9141437B2 (en) 2008-01-29 2015-09-22 International Business Machines Corporation Methods and systems for migrating network resources to improve network utilization
US8245236B2 (en) 2008-02-27 2012-08-14 International Business Machines Corporation Lock based moving of threads in a shared processor partitioning environment
US8561072B2 (en) 2008-05-16 2013-10-15 Microsoft Corporation Scheduling collections in a scheduler
US8458722B2 (en) 2008-06-09 2013-06-04 International Business Machines Corporation Thread selection according to predefined power characteristics during context switching on compute nodes
US9201673B2 (en) 2008-07-30 2015-12-01 Microsoft Technology Licensing, Llc Efficient detection and response to spin waits in multi-processor virtual machines
US9357247B2 (en) 2008-11-24 2016-05-31 Time Warner Cable Enterprises Llc Apparatus and methods for content delivery and message exchange across multiple content delivery networks
WO2010064277A1 (en) 2008-12-03 2010-06-10 Hitachi, Ltd. Techniques for managing processor resource for a multi-processor server executing multiple operating systems
JP5433676B2 (ja) 2009-02-24 2014-03-05 パナソニック株式会社 プロセッサ装置、マルチスレッドプロセッサ装置
US8676976B2 (en) 2009-02-25 2014-03-18 International Business Machines Corporation Microprocessor with software control over allocation of shared resources among multiple virtual servers
US9250973B2 (en) 2009-03-12 2016-02-02 Polycore Software, Inc. Apparatus and associated methodology of generating a multi-core communications topology
US8576862B2 (en) 2010-05-18 2013-11-05 Lsi Corporation Root scheduling algorithm in a network processor
US8291430B2 (en) 2009-07-10 2012-10-16 International Business Machines Corporation Optimizing system performance using spare cores in a virtualized environment
US8352946B2 (en) 2009-08-11 2013-01-08 International Business Machines Corporation Managing migration ready queue associated with each processor based on the migration ready status of the tasks
FR2950714B1 (fr) 2009-09-25 2011-11-18 Bull Sas Systeme et procede de gestion de l'execution entrelacee de fils d'instructions
US8413161B2 (en) * 2009-09-29 2013-04-02 International Business Machines Corporation Work queue selection on a local processor within a multiple processor architecture
KR101644569B1 (ko) 2009-10-01 2016-08-01 삼성전자 주식회사 가상 프로세서 관리 장치 및 방법
EP2323035B1 (en) 2009-11-16 2019-04-17 Red Bend Software Scheduling system
US9021046B2 (en) 2010-01-15 2015-04-28 Joyent, Inc Provisioning server resources in a cloud resource
US8424010B2 (en) 2010-01-21 2013-04-16 Mckesson Financial Holdings Shared resource management
US8656397B2 (en) 2010-03-30 2014-02-18 Red Hat Israel, Ltd. Migrating groups of threads across NUMA nodes based on remote page access frequency
US8689349B2 (en) * 2010-05-05 2014-04-01 Intel Corporation Information flow tracking and protection
US8443376B2 (en) 2010-06-01 2013-05-14 Microsoft Corporation Hypervisor scheduler
US8990531B2 (en) * 2010-07-12 2015-03-24 Vmware, Inc. Multiple time granularity support for online classification of memory pages based on activity level
US8838935B2 (en) 2010-09-24 2014-09-16 Intel Corporation Apparatus, method, and system for implementing micro page tables
US20120096462A1 (en) 2010-10-18 2012-04-19 Electronics And Telecommunications Research Institute Dynamic virtualization technique for multicore processor system
US8667496B2 (en) 2011-01-04 2014-03-04 Host Dynamics Ltd. Methods and systems of managing resources allocated to guest virtual machines
US8547840B1 (en) 2011-02-01 2013-10-01 Google Inc. Bandwidth allocation of bursty signals
US9201689B2 (en) 2011-04-22 2015-12-01 Cray Inc. Software emulation of massive hardware threading for tolerating remote memory references
US8683468B2 (en) 2011-05-16 2014-03-25 Advanced Micro Devices, Inc. Automatic kernel migration for heterogeneous cores
US8924541B2 (en) 2011-05-29 2014-12-30 International Business Machines Corporation Migration of virtual resources over remotely connected networks
US8863141B2 (en) 2011-12-14 2014-10-14 International Business Machines Corporation Estimating migration costs for migrating logical partitions within a virtualized computing environment based on a migration cost history
US8694995B2 (en) 2011-12-14 2014-04-08 International Business Machines Corporation Application initiated negotiations for resources meeting a performance parameter in a virtualized computing environment
US9317441B2 (en) 2011-12-22 2016-04-19 Intel Cororation Indexed page address translation to reduce memory footprint in virtualized environments
EP2798489A4 (en) 2011-12-26 2016-06-22 Intel Corp TERMINATION FOR VIRTUAL CENTRAL DATA PROCESSING UNITS ON VIRTUAL COMPUTERS BETWEEN PHYSICAL PROCESSING UNITS
US20130173806A1 (en) 2011-12-31 2013-07-04 Level 3 Communications, Llc Load-balancing cluster
US9229782B2 (en) 2012-03-27 2016-01-05 International Business Machines Corporation Collectively loading an application in a parallel computer
US20130332778A1 (en) 2012-06-07 2013-12-12 Vmware, Inc. Performance-imbalance-monitoring processor features
US20140024529A1 (en) * 2012-07-18 2014-01-23 Algae Aqua-Culture Technology, Inc. Biorefinery system, components therefor, methods of use, and products derived therefrom
US9191435B2 (en) 2012-08-23 2015-11-17 TidalScale, Inc. Selective data migration or remapping of virtual processors to provide required data accessibility to processor cores
US9501483B2 (en) 2012-09-18 2016-11-22 Mapr Technologies, Inc. Table format for map reduce system
US8875295B2 (en) 2013-02-22 2014-10-28 Bitdefender IPR Management Ltd. Memory introspection engine for integrity protection of virtual machines
US10114662B2 (en) 2013-02-26 2018-10-30 Red Hat Israel, Ltd. Updating processor topology information for virtual machines
US9971616B2 (en) * 2013-02-26 2018-05-15 Red Hat Israel, Ltd. Virtual machine suspension
US9774401B1 (en) 2013-07-15 2017-09-26 Paul Borrill Entangled links, transactions and trees for distributed computing systems
US9465669B2 (en) * 2013-08-13 2016-10-11 Vmware, Inc. NUMA scheduling using inter-vCPU memory access estimation
US9223574B2 (en) 2014-03-27 2015-12-29 International Business Machines Corporation Start virtual execution instruction for dispatching multiple threads in a computer
US9286104B1 (en) * 2015-01-05 2016-03-15 International Business Machines Corporation Selecting virtual machines to be relocated based on memory volatility
US10715460B2 (en) 2015-03-09 2020-07-14 Amazon Technologies, Inc. Opportunistic resource migration to optimize resource placement
US20160366183A1 (en) 2015-06-09 2016-12-15 Ned M. Smith System, Apparatus And Method For Access Control List Processing In A Constrained Environment
US10812408B1 (en) 2016-03-25 2020-10-20 Amazon Technologies, Inc. Preventing concentrated selection of resource hosts for placing resources
US10620992B2 (en) * 2016-08-29 2020-04-14 TidalScale, Inc. Resource migration negotiation

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5230069A (en) * 1990-10-02 1993-07-20 International Business Machines Corporation Apparatus and method for providing private and shared access to host address and data spaces by guest programs in a virtual machine computer system
US6016542A (en) * 1997-12-31 2000-01-18 Intel Corporation Detecting long latency pipeline stalls for thread switching
US6807616B1 (en) * 2001-08-09 2004-10-19 Advanced Micro Devices, Inc. Memory address checking in a proccesor that support both a segmented and a unsegmented address space
US8752058B1 (en) * 2010-05-11 2014-06-10 Vmware, Inc. Implicit co-scheduling of CPUs
JP2013135318A (ja) * 2011-12-26 2013-07-08 Canon Inc 画像処理装置、システム、制御方法、及びプログラム
CN105393255A (zh) * 2013-07-05 2016-03-09 比特梵德知识产权管理有限公司 用于虚拟机中的恶意软件检测的过程评估
CN103885838A (zh) * 2014-03-27 2014-06-25 北京大学 一种获取虚拟机内存工作集的方法及内存优化分配方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
云计算技术在核动力装置设计平台中的应用研究;彭辉 等;核动力工程;第34卷(第S1期);第214-217页 *

Also Published As

Publication number Publication date
US20180060121A1 (en) 2018-03-01
EP3504618A4 (en) 2020-05-06
US20180060120A1 (en) 2018-03-01
CN109923523A (zh) 2019-06-21
US10579421B2 (en) 2020-03-03
US20180060071A1 (en) 2018-03-01
US11403135B2 (en) 2022-08-02
EP3504618A1 (en) 2019-07-03
US20190361735A1 (en) 2019-11-28
US20200142733A1 (en) 2020-05-07
US10783000B2 (en) 2020-09-22
JP6924820B2 (ja) 2021-08-25
CN116401057A (zh) 2023-07-07
CN116401058A (zh) 2023-07-07
US10620992B2 (en) 2020-04-14
WO2018044794A1 (en) 2018-03-08
US10353736B2 (en) 2019-07-16
US20200192702A1 (en) 2020-06-18
JP2019528539A (ja) 2019-10-10
US11513836B2 (en) 2022-11-29

Similar Documents

Publication Publication Date Title
CN109923523B (zh) 计算机系统及用于计算机系统的方法
US11803306B2 (en) Handling frequently accessed pages
US11159605B2 (en) Hierarchical dynamic scheduling
EP3356936B1 (en) Network attached memory using selective resource migration
EP3042282A1 (en) Hierarchical dynamic scheduling
WO2015034506A1 (en) Selective resource migration

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20230224

Address after: Texas, USA

Applicant after: HEWLETT PACKARD ENTERPRISE DEVELOPMENT L.P.

Address before: California, USA

Applicant before: Hongchao Co.

GR01 Patent grant
GR01 Patent grant