功能即服务（FAAS）系统增强的制作方法

相关申请的交叉引用

本申请要求于2018年11月8日提交的pct临时专利申请no.pct/cn2018/114602的优先权的权益。

背景技术：

功能即服务(faas)是一种面向事件的高度可缩放的计算机代码执行模型，该模型通常在云计算基础设施上预设单目的的应用编程接口(api)端点以接收和运行针对少量时间的代码执行请求。此类代码执行请求和/或所请求的代码的执行被以各种方式且共同地称为lambda(λ)、功能、动作、和/或运行到完成过程。在本申请中，术语“功能”可以指代这些代码执行请求和这些请求的执行中的任一者，而不管此类执行作为软件进行，还是作为以硬件进行的动作进行、或是上述情况的任何组合。即，术语“功能”如本文所使用的可一般地指代faas功能，除非通过上下文以其他方式显式地和/或以其他方式隐式地表明。因此faas可以被认为是云计算进化的一步。有时候也被称为“无服务器计算”，faas可以使得软件开发人员能够编写高度可缩放的代码，但是却无需预设或以其他方式预定义执行代码将会涉及的硬件或应用软件资源所要求的成本、时间和花费。faas还能够使云服务提供商(csp)能够由于更好的分配(例如箱式打包)而增加资源使用。

随着增加对商业逻辑的关注并减少对云栈实现的关切/控制，大规模的计算单元已随着时间推移而改变。faas抽象了运行时环境，诸如公共语言运行时(clr)和执行上下文生命周期。例如应用开发人员和csp之类的用户可以通过faas捕捉到极大的价值。例如，开发人员使用高级语言来构建应用，诸如功能代码，并且将该功能代码上传到faas平台以供执行。开发人员简单地使用faas平台而无需由他们自身主存功能代码，并且faas平台的基础设施对于用户而言是不透明的。

在csp的情形中，虽然csp可使用其功能即服务的组合作为关键区分因素，但是仍然存在相当大的改进空间。例如，仍然存在围绕“专有锁定”的担忧，因为被写入云中且被部署在云中的功能代码在那个时刻变得与csp提供的功能密不可分地关联。该专有锁定意味着应用变得针对特定云环境被优化。相应地，在csp之间移动功能除了会导致csp提供的功能中的一些功能不被其他csp支持的情况之外还会牺牲应用的性能和响应性。

图2a例示了用于提供功能即服务的通用现有无服务器服务平台203，其接收由计算机应用开发人员上传的无服务器功能代码201，并且执行由对应事件触发的功能代码201。无服务器功能代码201的应用开发人员可以支付与仅在无服务器功能代码201在无服务器服务平台203中被调用和/或运行时相对应的量。如图2a所示，无服务器服务平台203具有无服务器服务管理器203a以接收无服务器功能代码201，将无服务器功能代码201存储到存储设备，并且使用所需要的计算机资源(诸如容器)来调度无服务器功能代码201的执行。无服务器服务平台203还可包括联网和消息收发模块203b以触发与执行无服务器功能代码201相关联的一个或多个事件并在csp网络的端点之间路由该一个或多个事件。无服务器服务平台203还可包括安全和访问管理器203c以及一个或多个存储服务203d。安全和访问管理器203c负责提供执行无服务器功能代码201方面的安全性。例如，安全和访问管理器203c可以验证对与执行无服务器功能代码201相关联的各个计算机资源和/或特权的访问。存储服务203d可包括对象存储设备(例如，亚马逊aws的lambda的s3)、密钥值数据库(例如，亚马逊aws服务的dynamo数据库)、和/或用于提供专用后端服务的移动后端数据库(例如，谷歌的云功能的cloudfirestore)。存储服务203d还可实现大数据服务，包括大数据查询(例如，awsathena和谷歌bigquery)和大数据转换(例如，awsglue和谷歌clouddataflow)。无服务器服务平台203通过无服务器服务架构203e(例如，awslambda的架构、谷歌cloudplatform(云平台)的架构、和/或azurefunctions(azure功能)的架构)以及一个或多个与硬件相关联的元件(诸如硬件辅助的虚拟机、cpu、gpu和加速器)来启用无服务器服务。

对于诸如图2a中示出的现有faas解决方案存在挑战。例如，现有faas解决方案通常提供不成熟的开发人员工具生态系统。此外，现有faas解决方案频繁地要求不可预测且成本高昂的冷启动，冷启动除了运行代码之外还包括使必要的执行环境准备好，并且这引发高的、可变的且不可预测的等待时间。以运行中的视频编码应用为例，可使用对象存储的现有解决方案过满而无法支持精细粒度的通信和/或在无服务器功能代码得以执行之前遭受漫长的等待时间。

此外，现有faas解决方案当前遭受管理代码执行状态方面的受限控制和困难。以大规模的机器学习训练为例，诸如图2a中示出的现有faas解决方案由于缺少快速和/或共享存储器以及缺少对联网连接性的足够支持而面临达成期望的高可缩放性方面的挑战。

另外，faas引入了额外的抽象层，这使得现有faas解决方案更难以在处理器、平台或系统(诸如用于支持硬件异构性的计算机架构)中暴露和锻炼相异和/或新基础设施特征。换言之，尽管现有faas解决方案可以抽象软件开发，但是此类抽象可能导致高效地利用硬件架构来执行软件代码方面的困难。

附图说明

通过阅读以下说明书和所附权利要求并通过参考以下附图，实施例的各种优势对本领域技术人员将变得显而易见，其中：

图1是根据实施例的faas计算环境的示例的例示；

图2a例示了通用现有无服务器服务的示例；

图2b是根据实施例的一组faas系统组件的示例的框图；

图3是根据实施例的faas服务器配置的示例的框图；

图4是根据实施例的增强的faas系统的示例的框图；

图5是根据实施例的增强的faas系统的子系统的示例的框图；

图6a是根据实施例的用于资源分配和控制的增强的faas架构的示例的框图；

图6b是根据实施例的使用增强的faas架构来管理用户级能力的流程图；

图6c是根据实施例的使用增强的faas架构来管理用户级能力的流程图；

图7a是根据实施例的用于监视各个虚拟功率性能监视单元(vpmu)事件的示例性faas计算节点的框图；

图7b是根据实施例的vpmu缓冲器的示例的框图；以及

图7c是根据实施例的监视功能的性能的方法的示例的流程图；

图8a是根据实施例的电子处理系统的示例的框图；

图8b是根据实施例的半导体封装装置的示例的框图；

图8c是根据实施例的在多个faas功能之间共享存储器的示例的流程图；

图8d是根据实施例的在多个faas功能之间共享存储器的示例的流程图；

图8e是根据实施例的提供多个faas功能之间的存储器共享的faas系统的另一示例的框图；

图8f是根据实施例的用于促成两个faas功能之间的通信的功能后备缓冲器的另一示例的框图；

图8g是根据实施例的用于编排分布式faas功能的faas系统的另一示例的框图；

图9a是根据实施例的提供功能即服务的推测执行之前的容器运行的方法的示例的流程图；

图9b是根据实施例的支持推测执行之前的容器运行的faas系统的另一示例的框图；

图9c是根据实施例的支持图像旋转功能的推测执行之前的容器运行的faas系统的另一示例的框图；

图10a是根据实施例的提供具有反馈支持的功能即服务的方法的另一示例的流程图；

图10b是根据实施例的具有反馈支持的faas系统的另一示例的框图；

图10c是根据实施例的具有反馈支持的faas系统的另一示例的框图；

图11a是根据实施例的具有多个用于实例化的选项的功能的示例的例示图；

图11b是根据实施例的支持具有多个用于实例化的选项的功能的faas系统的另一示例的框图；

图11c是根据实施例的提供用于具有多个用于实例化的选项的功能的功能即服务的方法的另一示例的流程图；

图12是根据实施例的具有调度器的faas系统的另一示例的框图；

图13a是根据实施例的faas服务器架构的示例的框图；

图13b是根据实施例的增强的faas调度过程的示例；

图13c是根据实施例的功能的流程图；

图14a和图14b是根据实施例的增强的功能执行序列的示例；

图14c是根据实施例的调度具有多个操作的功能的流程图；

图15a是根据实施例的用于faas的存储器存储增强的计算架构的示例的框图；

图15b是根据实施例的用于faas平台的容器和功能的存储器分配的流程图；

图16a是根据实施例的对功能执行的批量功能请求的示例。

图16b是根据实施例的半导体封装装置的示例的例示；

图16c是根据实施例的批量处理功能请求的流程图；

图16d是根据实施例的批量处理两个或更多个功能请求的流程图；

图16e是根据实施例的调度功能请求的流程图；

图17a是根据实施例的冗余功能实现的示例；

图17b是根据实施例的冗余功能实现的流程图；

图18a例示了根据实施例的表示用于faas的调度器的功能生成图；

图18b例示了根据实施例的具有调度器的增强的faas系统；

图18c是根据实施例的faas功能实现的流程图；

图19a是根据实施例的具有共用数据存储的增强的faas架构的示例；

图19b是根据实施例的示例性faas数据存储的流程图；

图19c是根据实施例的实现和实施faas安全协议的示例性方法的流程图；

图20a是根据实施例的具有专用faas高速缓存的增强的faas服务器架构的示例的框图；

图20b是根据实施例的具有通用高速缓存的增强的faas服务器架构的示例的框图；

图20c是例示根据实施例的数据对象的数据量的图的示例；

图20d是根据实施例的示例性增强的功能资源管理的流程图；

图21a是根据实施例的对软件线程排定优先级的方法的示例；

图21b和图21c例示了根据示例性实施例的在增强的faas架构中用于提供页级qos的页表中的任务和服务类(clos)之间的交互；

图21d例示了根据示例性实施例的与页级qos有关的另一架构；

图22例示了根据实施例的用于提供关于faas服务的确定性和准确性的示例架构；

图23是根据实施例的出于计费目的来计算资源使用的方法的示例；

图24a是根据实施例的分布式计算环境的示例的框图；

图24b是根据实施例的提供功能即服务的另一示例的流程图；

图25a是根据实施例的启用多个功能之间的存储器重用的faas系统的示例的框图；

图25b是根据实施例的提供功能即服务的方法的另一示例的流程图；

图26a是根据实施例的提供功能即服务的另一示例的流程图；

图26b是根据实施例的功能调用图的例示图；

图26c是根据实施例的拆分功能的例示图；

图26d是根据实施例的功能调用图的另一例示图；

图26e是根据实施例的合并功能的例示图；

图27a是根据实施例的具有由多个功能共享的存储器的增强的faas系统的另一示例的框图；

图27b是根据实施例的具有由多个功能共享的存储器的增强的faas系统的另一示例的框图；

图28a是根据实施例的提供功能即服务的流程图；

图28b是根据实施例的faas系统的另一示例的框图；

图29a是根据实施例的提供支持容器逆转特征的功能即服务的流程图；

图29b是根据实施例的支持容器逆转特征的faas系统的示例的框图；

图30a是根据实施例的提供具有延续(continuation)应用的功能即服务以实现改进的功能执行性能的流程图；

图30b是根据实施例的具有延续应用以实现改进的功能执行性能的faas系统的示例的框图；

图31a和图31b是根据实施例的用于faas的增强的容器构建和高速缓存管理的示例；

图31c是根据实施例的示例性高速缓存驱逐的流程图；

图31d是根据实施例的另一示例性高速缓存驱逐的流程图；

图31e是根据实施例的确定高速缓存的数据对象的存活时间的流程图；

图32a和图32b是根据实施例的增强的功能分发的示例；

图32c和图32d是根据实施例的增强的功能分发的示例；

图32e是根据实施例的功能分发的流程图；

图33a是根据实施例的faas的功能的增强的功能构造的示例；

图33b是根据实施例的根据增强的功能构造的名称(moniker)标识的流程图；

图34a是根据实施例的基于功能调用的频率使用调用图来预取功能的示例的例示；

图34b是根据实施例的用于增强faas功能的执行的方法的示例；

图35a是例示根据实施例的当前功能的之前功能的框图；

图35b是根据实施例的基于前驱功能来执行faas功能的方法的示例；

图36a例示了根据实施例的基于功能被执行的概率来维持容器的温暖度的示例；

图36b是根据实施例的执行来自温暖容器的faas功能的方法的示例；

图37a是例示根据实施例的基于大小的自适应存储器分层的框图；

图37b是例示根据实施例的基于使用的自适应存储器分层的框图；

图37c是根据实施例的用于对功能进行自适应存储器分层的方法的示例；

图38a例示了根据实施例的用于faas的快速类加载的环境；

图38b是根据实施例的在增强的faas计算环境中执行功能的方法的示例；

图38c是根据实施例的在增强的faas计算环境中执行功能的方法的示例；

图39a例示了根据实施例的促成按时间顺序的和云规模的(横向)反馈两者的连续应用的faas环境；

图39b例示了根据实施例的每一功能类型的不同向量；

图39c是根据实施例的预留恰适资源的方法的示例；

图40a例示了根据实施例的与代码优化有关的不同特性；

图40b是根据实施例的在增强的faas计算中执行功能的方法的示例；

图41a是示出根据实施例的需求指纹与功能执行之间的关系的图；

图41b例示了根据实施例的资源管理器的操作；

图41c是根据实施例的使用需求指纹的高效faas资源管理的方法的示例；

图41d是根据实施例的需求指纹的示例；

图42a是根据实施例的功能客户端与功能执行引擎之间的通信的示例；

图42b是根据实施例的使用不透明标记来执行faas功能的方法的示例；

图43a是根据实施例的基于唯一地标识功能上下文的令牌的服务器位置选择的示例的例示；

图43b是根据实施例的管理功能调用的流程图；

图43c是根据实施例的管理功能调用的详细方法的流程图；

图43d是faas系统的示例的框图，其中功能调用的位置基于请求源来选择；

图43e是faas系统的示例的框图，其中功能调用的位置基于功能调用树来选择；

图44a是根据实施例的跨域控制传递的示例的框图；

图44b是根据实施例的操作远程过程被调用方的流程图；

图44c是根据实施例的操作远程过程调用方的流程图；

图45a是根据实施例的faas架构的示例的框图，其中应用层功能与数据面功能并置；

图45b是根据实施例的操作运行时框架的流程图；

图46a是根据实施例的定制响应对象解决方案的示例的例示；

图46b是根据实施例的定制调用实例的响应对象的流程图；

图47a是根据实施例的参数编组(marshall)解决方案的示例的例示；

图47b是根据实施例的统一地调用跨平台的功能的高级架构的示例的图示；

图47c是根据实施例的对功能参数进行编组的流程图；

图48a是根据实施例的在功能之间传递能力信息的示例的框图；

图48b是根据实施例的编码内联能力(eic)信息的示例的框图；

图48c是根据实施例的硬件队列管理器的示例的框图；

图48d是根据实施例的操作硬件队列管理器的流程图；

图48e是根据实施例的使能力入队列的流程图；

图48f是根据实施例的使能力出队列的流程图；

图49a是根据实施例的密钥标识符与密钥之间的映射的示例的例示；

图49b是根据实施例的单个地址空间的示例的框图；

图49c是根据实施例的上下文切换的示例的框图；

图49d是根据实施例的密钥标识符映射更新的示例的框图；

图49e是根据实施例的更新密钥标识符映射的流程图；

图49f是在虚拟地址与物理地址之间进行映射的转换后备缓冲器/页未命中处置器的示例的框图；

图50a是根据实施例的保护密钥标识符更新指令的示例的框图；

图50b是根据实施例的更新保护密钥标识符的流程图；

图51a是根据实施例的被准许修改子页许可的无特权组件的示例的框图；

图51b是根据实施例的控制子页许可的流程图；

图52a是根据实施例的包括能力信息约束的被剥夺特权的模式路径的示例的例示；以及

图52b是根据实施例的控制存储器访问的流程图。

具体实施方式

图1示出了根据一个实施例的faas计算环境。开发人员编写代表一个或多个计算机功能的功能代码100(在此处也被称为“计算机代码”)，并且功能代码100被上传到例如csp数据中心104中的faas平台102。触发事件106(诸如举例来说用例或物联网(iot)事件)发起功能代码100在faas平台102处的执行。功能代码在其中被执行的环境被称为容器。容器可以是任何隔离执行的实体，诸如进程、docker容器或kubernetes容器、虚拟机等。在其自身的虚拟机中运行的容器被称为虚拟容器，在csp数据中心104(包括csp对其具有控制的faas平台102、它们的数据中心、边缘环境和iot(包括移动)设备)内，基础设施按需被“旋转加速”(例如，激活和/或分配)和缩放。功能代码100能够在csp的物理基础设施/边缘/iot设备和底层虚拟化容器上执行。最后，基础设施响应于执行完成而被“旋转减速”(例如，解除激活和/或解除分配)。

如下文将更详细地讨论的，本文描述的技术通过提供增强的faas特征减少了围绕专有锁定、高成本冷启动、等待时间、以及对代码执行状态的管理/控制的担忧，该增强的faas特征诸如响应于事件按需运行功能代码，并且基于原子规模单元随着事件数目自动缩放，该原子规模单元将功能代码及其对应的功能部署为计算规模单元。本文描述的技术通过启用增强的广度，允许平台的多样性和/或直接用硬件以及通过标准库或运行时启用安全性来进一步减少上述担忧。另外，本文描述的技术使得展示和练习新硅特征变得更容易。通过使开发人员能够使用被cspfaas平台支持的较高级的语言来构建应用，并且简化操作、优化、灵活性和缩放，本文描述的技术可进一步使得非专家级开发人员有能力实现稳健、高性能和安全的faas解决方案，该faas解决方案透明地获益于在硬件中传递的加速能力。本文描述的技术可进一步简化编码，并且驱动对由cspfaas平台进行的计算的更多需求。

图2b示出了如文本所描述的增强的faas系统202的组件200(200a-200b)的示例。与关联于诸如图2a所示的现有faas服务的挑战相比，增强的faas系统202提供了诸多增强，诸如在面向事件的执行环境中的高效的功能代码执行，这要求最少的管理同时提供高可缩放性和粒度计费。在例示的示例中，事件取向组件200a确保功能代码响应于事件按需运行，最少管理组件200b通过faas服务提供商将执行功能代码的基础设施管理从用户(例如，代码开发人员)抽象出来，高可缩放性组件200c随着事件(例如，用户事件或与iot有关的事件)数目自动缩放功能代码执行，原子规模单元组件200d将计算机代码及其对应功能部署为计算规模单元，并且粒度计费组件200e使得消费者(例如，计算机代码开发人员)能够仅在他们的代码得以执行时才支付并且消费者按照例如100毫秒的增量被计费。增强的faas系统202还可包括其他有利的组件，如将在下文更详细地讨论的。

用户和csp因此将通过增强的faas系统202获得极大的价值。增强的faas系统202为用户提供的价值包括例如对感兴趣的操作的开发的增加的聚焦，缩短的上市时间(ttm)，减少的基础设施管理，以及降低的总所有权成本(tco)。对于csp，增强的faas系统202提供的价值包括例如驱动高利润服务的采用、针对每一计算单元挣取更多、启用新的云工作负载、改进的成本摊销、调度计算资源方面的弹性、以及提供与其他csp竞争的能力。

在实施例中，存在增强的faas系统202的五个组件。第一个组件是用于创建功能并且执行功能的计算机代码的功能格式组件。功能格式组件的一个示例是如图3所例示的faas执行器310、324、319、315(在下文讨论)。第二个组件是用于将事件调用路由到功能的事件处置api代理组件。事件处置api代理的一个示例是图4的用户接口处置器402(在下文讨论)。第三个组件是接收、存储功能代码封装并确保其安全的功能代码存储。功能代码存储的一个示例是图4的网络、存储和存储器管理器408(在下文讨论)。第四个组件是提供功能执行环境的faas容器，在该功能执行环境中，功能代码被下载并被实例化在容器中或实例化在其他隔离执行替换物中。faas容器的一个示例是图4的faas架构406(在下文讨论)。在执行之后，容器被擦除(或重置、重初始化等)以用于新的功能。为了安全和隔离，容器常常在虚拟机(vm)内运行。最后一个核心组件是用于通过针对功能代码(例如，“冷引导”)加速旋转容器来优化容器在可用计算资源内的放置的功能/容器编排组件。功能/容器编排组件的一个示例是图4的编排器404(在下文讨论)。如果一个功能最近运行过，则新的功能可以被放置在已经“温暖”的容器中，从而减小实例化等待时间。温暖的容器可以是最近被用于执行功能的容器，或者被频繁用于功能执行的容器。代替在功能完成之后将容器拆除，容器可以被保留以供将来的功能执行。因而，容器可以被认为是“温暖”的，因为该容器不必被构建且已准备好立即执行功能。

图3示出了用于向用户/csp提供增强的faas性能的faas服务器配置300。在所例示的例示中，faas服务器配置300包括智能网络接口卡(nic)302，其包括在增强的faas衬底306上的faas管理逻辑304。在一些实施例中，智能网络接口卡302用作faas服务器配置300的控制中心。faas服务器配置300包括一个或多个计算机代码执行单元，其被配置成按照经编排的方式来执行多个功能集。在其他实施例中，faas管理逻辑304和增强的faas衬底306可以以各种方式被实现在以下各者中：基板管理控制器(bmc)、处理器、在处理器上执行的软件模块、专用功能逻辑、和/或被实现为上述情况的任何组合。在所例示的示例中，一个或多个中央处理单元(cpu)308a-308n(例如，主机处理器)使用faas执行器310来执行第一功能集312，一个或多个加速器314a-314n(例如，固定功能的硬件逻辑)执行第二功能集316，一个或多个现场可编程门阵列(fpga)318a-318n执行第三功能集320，并且一个或多个图形处理单元(gpu)318a-318n执行第四功能集326。相应地，所例示的faas服务器配置300由专用硅来赋能，这些专用硅包括gpu322a-322n、fpga318a-318n和专用加速器314a-314n。faas服务器配置300可包含多个cpu308a-308n、gpu322a-322n、fpga318a-318n和其他专用加速器314a-314n。

值得注意的是，专用加速器314a-314n彼此可以是不同类型的。例如，专用加速器314a-314n中的每一者可以被专门设计成用于加速某些功能或图元(例如，被专门设计成用于机器学习(ml)模型的训练期间的矩阵乘法的加速器、用于更高效的功率和能耗的加速器、和/或用于某些计算和数据的更佳的安全性和隐私的加速器)。

类似地，faas服务器配置300的cpu308a-308n可以是彼此不同的架构(例如，由不同提供商制造且具有不同的示意以及架构)。例如，在一些实施例中，cpu308a-308n可以是英特尔架构、高级精简指令集计算机机器处理器、无联锁流水线级处理器的微处理器、以及精简指令集计算机-v(risc-v)处理器中的各个处理器的组合。在一些实施例中，cpu308a-308n可全部都具有相同的架构(例如，全部都是英特尔架构)。类似地，gpu322a-322n可以是彼此相同或可以是彼此不同(例如，由不同提供商制造且具有不同的示意)的架构。类似地，fpga318a-322n可以是彼此相同或可以是彼此不同(例如，由不同提供商制造且具有不同的示意)的架构。此外，专用加速器314a-322n可以是彼此相同或可以是彼此不同(例如，由不同提供商制造且具有不同的示意)的架构。此外，执行单元、cpu308a-308n、gpu322a-322n、fpga318a-318n和专用加速器314a-314n除了数字设计之外还可利用模拟设计。

faas工作负载可能具有与传统工作负载不同的特性，例如，就工作负载的更精细(例如增加的)粒度而言。工作负载的增加的粒度使得利用专用硅(诸如加速器314a-314n和fpga318a-318n)的优点变得更容易。通过分解多个功能集，faas服务器配置300使得csp能够将每一工作负载(例如，转码、推理、专用操作等)与最优的硅部件(诸如加速器314a-314n、fpga318a-318n、cpu308a-308n、gpu322a-322n等)进行匹配。专用于faas的硬件，诸如图3中描述的faas服务器配置300，能够改进faas性能以及更多用户和csp的采用。增强的faas解决方案提供高灵活性和异构性以实现与现有解决方案相比改进的执行特性。

faas服务器配置300可包括更多或更少的所例示的组件。例如，在一个示例中，faas服务器配置300可包括一个cpu，诸如第一cpu308a。在另一示例中，faas服务器配置300可包括一个fpga(诸如第一fpga318a)和一个cpu(诸如cpu308a)。在又一示例中，faas服务器配置300包括第一加速器314a但不包括cpu308a-308n中的任一者。在又一示例中，faas服务器配置300包括多个cpu308a-308n、多个gpu322a-322n、诸如fpga318a的一个fpga、以及不同类型的多个专用加速器314a-314n。

现在转向图4，示出了增强的faas系统400的实施例。所例示的系统400包括用户接口处置器402，编排器404，faas架构406，网络、存储、存储器管理器408和安全管理器410。在实施例中，系统400接收要使用faas架构406来执行的faas功能代码412，faas架构406提供容器/功能执行环境。所例示的系统400还检测由系统400接收到的一个或多个faas事件414，诸如对执行用户的计算机代码的用户请求，该计算机代码例如faas功能代码412。响应于faas事件，对应的功能代码412被下载和实例化到系统400的容器或另一隔离执行的替代物中。用户接口处置器402是将事件调用路由到计算机代码412的对应功能的事件处置api代理。编排器404通过针对功能代码412使容器或其他执行引擎旋转加速来优化功能在可用计算资源内的执行(例如，无论是由容器、虚拟机还是进程等执行)。如果功能最近在容器中运行过，则该容器被标记为“温暖”容器。编排器404可以将新功能置于已经“温暖”的容器(以及更一般地准备好的执行引擎)中，从而减少实例化等待时间。术语“容器”如本文所使用的可以被认为是用于代码(诸如功能代码412)的任何形式的执行引擎。容器可以是进程、进程群、虚拟机、进程地址空间内的沙箱环境、虚拟机内的进程等。网络、存储和存储器管理器408可以接收和存储功能代码412，功能代码412由安全管理器410确保安全。在一个示例中，安全管理器410为了安全和隔离来确保容器在vm内运行。

编排器404还可包括以下子组件：遥测管理器416、简档管理器418、机器学习/人工智能(ml/ai)建议器420、以及服务水平协议/服务质量(sla/qos)管理器422。编排器404可以对数据进行概况分析，该数据诸如举例来说如参照图13a-13c的各实施例描述的功能的资源需要和/或需求简档，如参照图24a-24b的各实施例描述的功能的静态和动态简档信息，以及如下文参照图40a-40b描述的动态简档。

此外，遥测管理器416可以监视和记录功能的资源需要，例如作为度量数据(例如，高速缓存随着时间的使用情况)，和/或如图13a-13c的各实施例中描述的需求简档，参照图7a-7c讨论的在功能执行期间产生的后台性能监视和特定性能遥测，如参照图22的各实施例描述的带外(oob)遥测，如参照图24a-24b的各实施例描述的遥测和简档信息，以及如参照图36a-36b的各实施例描述的遥测信息。此外，sla/qos管理器422可以被用于确定如参照图21a-21d的各实施例描述的基于地址的qos、服务类、页级qos和/或线程级qos，以及如参照图39a-39c描述的符合qos的执行、qos清单向量、qos混合、安全向量和/或qos规范。

将理解，编排器404、遥测管理器416、简档管理器418、ml/ai建议器420以及sla/qos管理器422可以用各种方式被组合和利用以执行本文描述的任何实施例。此外，编排器404的不同布置可以被使用，其中仅遥测管理器416、简档管理器418、ml/ai建议器420和sla/qos管理器422的子集是编排器404的一部分。

在一些实施例中，增强的faas系统400通过遥测管理器416来收集与正被执行的功能相关联的遥测信息。遥测信息可以作为关于该功能的简档信息的一部分被使用，并且被简档管理器418存储。为了将功能执行映射到不同执行单元以增强效率同时满足功能的将来调用的要求(例如，时间和/或成本约束)，sla/qos管理器422除了向ml/ai建议器420寻求建议和/或指导之外，还可以查询简档管理器418的简档信息。在一个实施例中，ml/ai建议器420可以基于先前观察到的场景来执行异常检测，并且采取正确的动作和/或向sla/qos建议器422给出建议。

编排器404可以高效地放置faas功能以供执行。除了嵌入在编排器404中的基于算法和规则的机制，ml/ai建议器420可以在调度功能方面引导编排器404。由于faas系统400的连续操作，大量的“遥测”数据可以被遥测管理器416收集。此类遥测数据可以捕捉功能在系统的不同范围的系统上以及在不同时间/位置处的执行特性。遥测信息可包括各种属性，诸如cpu利用、存储器消耗、高速缓存分层结构行为、i/o和联网行为、执行的时间/位置、功耗/能耗、功能及其数据的安全/隐私方面(例如，安全要求和恶意攻击检测)、调用功能的用户和应用、功能所使用的参数和数据等。

简档管理器418可以处理收集到的遥测信息(实时地以及离线地)，生成信息汇总，并且寻找功能执行行为的相关性和反相关性。编排器404接着可以在确定功能放置的各方面(诸如时间、节点、加速器使用等)之前查询简档管理器418以及ml/ai建议器420。

例如，编排器404可以避免在同一时间将两个或更多个cpu密集型功能调度在同一处理器上。取而代之，编排器404可以将cpu密集型功能与存储器饥饿型功能(例如，要求大量存储器或具有较大数目的处理器高速缓存未命中或这两者的功能)调度在同一处理器上。此外，编排器404可以避免在同一时间将多个i/o密集型功能调度在同一系统上，且以此类推。因而，编排器404可以确保faas服务器的资源消耗被均衡。

此外，除了嵌入在编排器404中的此类规则之外，ml/ai建议器420可以向由遥测管理器416收集且由简档管理器418处理的大量的过去信息自动学习。例如，由简档管理器418收集和构建的ml模型可以在自动确定用于执行的功能的放置方面辅助ml/ai建议器420。作为示例，该信息可包括由简档管理器418收集和处理的可能的ml模型。ml模型可以揭示在同一系统上同时执行的某些功能集合将会导致异常差的执行特性(例如，异常、高等待时间执行等)。

编排器404可以确定和记录在其控制下在所有服务器上运行的功能及其状态。编排器404还可以是分布式编排器的集合，每一个编排器负责faas服务器的子集。当新功能要被放置以供执行时，编排器404可以查询ml/ai建议器并寻求功能放置的引导。

由此，编排器404可以是“自适应的”。随着遥测数据被遥测管理器416不断地收集，增强的faas系统400可持续地学习关于功能执行行为。这一方面可使得增强的faas系统400能够自动学习关于之前未被faas系统400分析过的新功能以及学习关于相移(例如，功能执行行为方面的突然和/或显著改变，诸如cpu使用、存储器消耗、i/o操作、以及网络交互等方面的改变)和季节性效应。季节性效应可包括外部事件，这些外部事件的在时间上的发生和频率影响功能执行和执行特性。例如，受到季节性效应影响的功能可包括启用因特网的gps，其被道路交通所驱动，可能在高峰时段或国定假日期间被更频繁地执行。另一示例可包括在常规工作时间之后执行视频内容的流传输应用。例如，增强的faas系统400可自动地检测对执行特定功能群或对特定数据集的访问的调用突然猛增。此类信息随后可导致将更多的faas服务器设置为用于执行，或者将数据移动到更靠近功能执行的位置，包括从数据中心移动到网络边缘，和/或在具有分解的存储器架构的平台中分配更多的存储器。

图5示出了包括子系统的增强的faas系统500的实施例。在所例示的示例中，faas系统500包括用户体验子系统502、安全子系统504、软件子系统506(506a-506c)和硬件子系统508(508a-508d)。软件子系统506可包括库506a、框架506b、平台和编排模块506c等。另外，所例示的硬件子系统508包括cpu508a、gpu508b、存储器和存储508c、联网组件508d、加速器508e(例如fpga)等。增强的faas系统500接收要被执行的faas功能代码510，并且响应于一个或多个相关联的faas事件512来执行功能代码510。

增强的faas系统500因此通过为特征货币化创造机会而适于更多样化的市场。对于例如通信服务提供商(cosp)和不拥有边缘位置的区域csp之类的较小服务提供商，faas代表更多参与到下一波端到端应用和服务的机会。许多下一代应用和服务可能需要应用或服务的一部分在消费者或企业附近被执行或提供。与提供具有全部开发和运营(devops)工具、api、和例如超规模csp提供的服务的丰富的平台即服务(paas)相比，在这些边缘站点主存小型功能组合对于较小型的参与者而言是一个容易得多的任务。

增强的faas系统500通过增加计算资源的租期、规模和利用来改进现有faas架构并且拓宽faas参数。faas可能成为开发基于云的技术的默认模式，从而将开发人员从后端基础设施维护中解放出来并且将编程向更多人开放，仅举几个例子。以此方式，增强的faas系统500具有为开发人员提供全新工作方式的潜力。例如，所例示的系统500支持和/或直接提供扩增和扩展faas提供商提供物的软件。faas服务提供商获益于对具有更好工具的faas解决方案的较低障碍，同时用户体验到由系统500提供的增加的使用便利。

尽管本文的某些示例是关于faas功能来讨论的，但是各个概念更宽泛地适用于其他类型的软件舱，诸如举例来说非faas容器、桌面应用等。

增强的faas架构

增强的faas系统(例如，图4和图5中例示的faas系统)还可提供用于使用软件功能和/或加速功能(例如，fpga或其他可配置逻辑)来直接控制硬件特征的用户级能力。此类办法对于支持固态驱动器(ssd)块设备的特权维护功能、用于加速器的管理功能等可能是有利的。因为功能是不会长久存在的运行直到完成的任务，所以对于功能对硬件的使用的基于硬件的控制与要求其他平台层软件(例如，平台层软件的功能无法与用户级软件的任何其他功能相区分)来调解此类访问相比提供更多效率和透明度。

图6a示出了用于资源分配和控制的增强的faas架构600。在所例示的架构600中，第一功能602(“f1”)包括要在cpu容器608内执行的代码604和安全证明令牌606。所例示的第一功能602还与元数据610相关联，元数据610定义用户级能力集，例如，用户级能力614、618、622、626。在一个示例中，用户级能力集与容器608外部的一个或多个特征相对应。例如，os612中的特征614可包括存储器管理、系统调用等、或其任何组合。另外，vmm616(虚拟机监视器，例如，管理程序)中的特征618可包括存储器管理、设备管理、网络重配置、对网络路径的访问、虚拟软件重配置等、或其任何组合。在实施例中，cpu620中的特征622包括资源指导器技术(rdt)监视器计数器，rdt高速缓存和存储器控制，平台服务质量监视器计数器，平台服务质量高速缓存和存储器控制，硬件性能监视计数器，对dram、3dxpoint、存储设备的更直接控制，或其任何组合。此外，加速器624(例如，fpga)中的特征626包括硬件重配置、比特流(例如，fpga实现图像)、设备重置等、或其任何组合。

如果与功能602相关联的安全证明令牌606对于伪造且被绑定到第一功能602的激活的某一可枚举、可发现、或可验证的属性如果不是不可能的也可能是困难的。因而，如果os612中的验证模块628和/或vmm616中的验证模块630确定安全证明令牌606有效，则第一功能602被准许使用特征614、618、622和626(例如，与用户级能力相对应)。所例示的来自第一功能602的曲线箭头代表第一功能602可以在容器608内以及在容器608外作出的各种调用。在一个示例中，带许可的特征不能被保留或以其他方式被阻止由vmm616、os612或其他软件“主管”(例如，管理程序主机、客os)暴露于第一功能602。实际上，架构600可以扩展/扩充用户级能力集，只要该扩展不会造成正确性违背(例如，协议和/或语法错误)或安全性违背。扩展可包括例如os/vmm计数器的经过滤视图、对os/vmm操作的定制控制，诸如“关联”(例如，实施在vm与主机之间建立关系的关联规则)、或用于存储器分层的策略提示等。然而，如果确定安全证明令牌606是无效的，则架构600阻止第一功能602对用户级能力的使用，并且以默认特征继续执行。因而，第一功能602可直接调用(例如，命令)容器608外部的特征从而绕开容器608。

图6a中例示的加速器624还包括实现用于重配置加速器624的单独功能的一个或多个虚拟接口632(632a-632c)。在一个示例中，第一功能602经由第一虚拟接口632a来重配置加速器624，第二功能634(“f2”)经由第二虚拟接口632b来重配置加速器624，并且第三功能636(“f3”)经由第三虚拟接口632c来重配置加速器624。因此，虚拟接口632能够实现faas架构(诸如图6a中例示的架构)中的单根io虚拟化(sr-iov)和/或串联快速io(srio)的使用。

现在转向图6b，图6b例示了使用增强的faas架构(诸如图6a中示出的架构)来管理用户级能力的方法640。方法640可以被普遍地实现在增强的faas系统中，该增强的faas系统诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、系统400(图4)、和/或系统500(图5)。更具体地，方法640可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框642提供了检测与在容器内执行的功能相关联的安全证明令牌。例如，在编排器将功能发送给功能调用器时，编排器提供所要求的安全证明令牌。此外，调用器可以维护此类安全证明令牌的注册表，并且是依赖于框架的。安全证明令牌可以由调用器或编排器在例如由功能的开发人员或消费者向编排器注册该功能之前被生成。

可以在框644通过验证签名或其他适用的方法来作出关于安全证明令牌是否有效的确定。如果是，则框644准许功能对用户级能力集的使用(例如，直接访问)，其中该用户级能力集与容器外部的一个或多个特征相对应。能力集可包括例如自监视、对虚拟空间的一部分的控制、对某一范围的页的读保护的控制、对某一范围的页的写保护的控制、用于存储在持久存储器中的对象的名称空间的建立、存储器管理、系统调用管理、设备管理、网络配置、对网络路径的访问、虚拟软件重配置等等。此外，各个特征可以是主机处理器(例如cpu)特征、os特征、虚拟机(例如vmm)特征、加速器特征等。此外，各个特征可包括使用特定技术对faas架构的各组件的粒度保留或优先级排定(诸如处理器共享、高速缓存共享、i/o吞吐量共享、加速器共享等)，该特定技术诸如资源指导器技术(rdt)或在gpu、asic、pcie中枢、fpga等中实现的类似技术。

另外，可以在框648作出关于用户级能力集的扩展是否会造成正确性违背(例如，协议和/或语法错误)或安全性违背的确定。如果否，则所例示的框650响应于扩展不造成正确性或安全性违背的确定来执行该扩展。如果在框648确定扩展将造成正确性或安全性违背，则方法640终止。如果在框644确定安全证明令牌无效，则框652阻止功能对用户级能力集的使用。

现在转向图6c，图6c例示了使用增强的faas架构(诸如图6a中示出的架构)来管理用户级能力的方法660。方法660可以被普遍地实现在增强的faas系统中，增强的faas系统诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、系统400(图4)、和/或系统500(图5)。更具体地，方法660可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框662提供了通过验证签名或其他适用方法来确定与功能相关联的安全证明令牌是有效的。功能可以在容器内执行。框664确定该功能是否使用和/或要求访问一个或多个不可用的资源和/或特征。例如，框664可以在资源或能力在用户级不可用和/或对容器不可用时确定该资源或能力是不可用的。能力源可包括例如自监视、对虚拟空间的一部分的控制、对某一范围的页的读保护的控制、对某一范围的页的写保护的控制、用于存储在持久存储器中的对象的名称空间的建立、存储器管理、系统调用管理、设备管理、网络配置、对网络路径的访问、虚拟软件重配置等等。各个资源可以是主机处理器(例如cpu)特征、os特征、虚拟机(例如vmm)特征、加速器特征等。此外，各个能力和/或资源可包括使用技术对faas架构的各组件的粒度保留或优先级排定(诸如处理器共享、高速缓存共享、i/o吞吐量共享、加速器共享等)，该技术诸如资源指导器技术(rdt)或在gpu、asic、pcie中枢、fpga等中实现的类似技术。

如果是，则框666枚举用户级访问需要的所需资源和/或能力。在一些实施例中，框666可进一步包括关于用户级资源和/或能力集的扩展是否会造成正确性违背(例如，协议和/或语法错误)或安全性违背的检查，并且不枚举造成违背的任何资源和/或能力。框668添加所枚举的资源和/或能力。例如，框668将所枚举的资源和/或能力临时添加到该功能的容器。临时添加在该功能的历时内维持。框670启用对所枚举的资源和/或能力的用户级访问。

在框670执行之后或者在该功能不使用任何不可用资源和/或能力的情况下，所例示的框672确定是否要启用任何可任选的、附加的资源和/或能力。框672咨询描述对性能有益或增强简易性的可任选的、附加的资源和/或能力(例如，约束(pindown)页的能力、关联线程的能力等)的表。如果是，则框674可以枚举可任选的、附加的资源和/或能力。如上文已经描述的，框674可以进一步执行检查以确定在特定可任选的、附加的资源和/或能力被枚举并被允许用于用户级访问的情况下是否会发生正确性违背(例如，协议和/或语法错误)或安全性违背。如果对于特定可任选的、附加的资源和/或能力将发生安全性或正确性违背，则该特定可任选的、附加的资源和/或能力不被枚举。由此，框674将仅枚举安全且稳定的可任选的、附加的资源和/或能力。即，仅不造成安全性问题且不对系统的稳定运作带来风险(诸如死锁、活锁、饥饿等)的可任选的、附加的资源和/或能力将被枚举。框676准许在功能执行的历时内对安全且稳定的附加资源和/或能力的用户级访问。

在框676完成之后，该方法终止。如果框672确定将不启用进一步的能力和资源，则该方法终止。

值得注意的是，方法640和660可以被修改和组合在一起。例如，框664、666、668、670、672、674、676可以被替换为框646、648、650中的一者或多者。

附加注解与示例

示例601包括至少一种计算机可读存储介质，其包括一组计算机可执行程序指令，该计算机可执行程序指令在由计算设备执行时致使该计算设备：检测与在容器内执行的功能相关联的安全证明令牌，在安全证明令牌有效的情况下准许功能对用户级能力集的使用，以及在安全证明令牌无效的情况下阻止该功能对用户级能力集的使用，其中该用户级能力集与该容器外部的一个或多个特征相对应。

示例602包括示例601的至少一种计算机可读存储介质，其中该程序指令在由该计算设备执行时致使该计算设备：在安全证明令牌有效的情况下执行该用户级能力集的至少一个扩展，其中在用户级能力集的扩展不造成正确性违背或安全性违背的情况下安全证明令牌有效。

示例603包括示例601的至少一种计算机可读存储介质，其中该用户级能力集从包括以下各项的组中选择：自监视、对虚拟空间的一部分的控制、对某一范围的页的读保护的控制、对某一范围的页的写保护的控制、用于存储在持久存储器中的对象的名称空间的建立、存储器管理、系统调用管理、设备管理、网络重配置、对网络路径的访问、以及虚拟软件重配置。

示例604包括示例601的至少一种计算机可读存储介质，其中从包括以下各项的组中选择一个或多个特征：主机处理器特征、操作系统特征、虚拟机特征、以及加速器特征。

图7a示出了faas计算节点，其中在功能714在容器702内执行期间在功能或容器级别监视各个虚拟功率性能监视单元(vpmu)事件700。事件700可以被配置成经由启用嵌套监视的架构接口704(例如，硬件和/或软件)来监视。关于嵌套，监视可以按照与在虚拟机客户机中、在裸金属操作系统中、或在裸金属容器中完成相同的方式在容器内完成或者甚至在功能内完成。换言之，测量某一架构事件(例如，被执行的指令数目、高速缓存未命中被计数的数目等)的能力或对软件事件计数器(诸如页错误的数目、被调入或调出的页、接收或传送的分组数目等)进行采样的能力不取决于从何处读取计数器。此外，在每一个级别处的测量都是可能的以获得读数，该读数反映该特定级别(例如，功能、容器、客户机os、主机os等)对读数的贡献。

在所例示的示例中，事件700包括执行的时间、每周期指令(ipc)、存储器带宽、高速缓存使用、每秒i/o操作(iop)和网络带宽，虽然还可以监视/收集其他事件。要被监视的事件700的编程可以通过系统软件能力来统一。在一个示例中，由例如容器702和/或主机提供的vpmu驱动器执行事件700的统一。如将更详细地讨论的，事件700可以经由各个虚拟pmu计数器(例如，镜像其他计数器的“影子”计数器)来跟踪。

例如，在时间t0，生成与功能714在容器702中的执行相关联的计数器值的第一快照706。类似地，可以在时间tn生成计数器值的第二快照708，可以在时间tn+1生成计数器值的第三快照710，并且以此类推。计数器值可一般地量化事件700中的一个或多个，其中快照706、708、710可以响应于新指令、新接口调用等来生成。用硬件来实现快照706、708、710可以使软件开销最小化。快照706、708、710中的一者或多者可以是在软件嵌套的更深级别处镜像其他预先存在的快照的其他部分的影子快照。快照706、708、710和/或快照706、708、710之间的差别(例如差值)被存储在vpmu缓冲器712中，该vpmu缓冲器712可以用作用于功能714的暂存区域。在所例示的示例中，vpmu缓冲器712经由api端点720(例如，超文本传输协议/http端点)被暴露于功能714、编排器716、或节点管理器718中的一者或多者。

所例示的解决方案因此可以被用于防止为每一功能调用提供有限存储器资源的faas基础设施中的容量或带宽意义上的饥饿。更具体地且作为示例，功能714的开发人员可以通过编程vpmu来经由快照706、708、710获得os度量、存储器高速缓存和存储器访问统计数据等来监视功能714是否遭遇以及遭遇了多少存储器页交换或高速缓存颠簸。另外，多个节点级vpmu可以组成分布式vpmu。

现在转向图7b，示出了vpmu缓冲器722，其中与功能726的执行相关联的第一度量数据724(例如，遥测快照和/或快照之间的差异)被提供给功能726和容器软件728。在所例示的示例中，容器软件728执行第一度量数据724(例如，高速缓存随着时间的使用)的聚合并且基于该聚合来生成第二度量数据730。另外，功能726可以收集和处理第一度量数据724以生成第三度量数据732。

现在转向图7c，示出了监视功能的性能的方法734。方法734可以被普遍地实现在增强的faas系统中，诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、系统400(图4)、和/或系统500(图5)。更具体地，方法734可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框736提供了在执行的第一时间点生成与容器中的功能执行相关联的计数器值的第一快照，其中在框738在执行的第二时间点生成计数器值的第二快照。在一个示例中，框740将第一快照、第二快照、或第一快照与第二快照之间的差别中的一者或多者存储到vpmu缓冲器。另外，在框742，vpmu缓冲器可以经由api端点被暴露于功能、编排器、或节点管理器中的一者或多者。

本文描述的技术因此使得功能开发人员能够结合容器或任何其他执行引擎来工作以经由后台性能监视来划分在功能执行期间产生的特定性能遥测的边界。相应地，事件取向、最少管理、高度可缩放性、资源规模单元和粒度计费也都可以被实现。这进一步准许对所收集的快照数据的特权-恰适的视图。例如，主存功能代码的容器软件模块可以观察和/或标识可能被开发人员提供的模块遮挡的一些事件。例如，由于不同的架构，在功能代码被主存在开发人员提供的模块中时，功能代码可能无法展现某些趋势，但是当被主存在容器软件模块内时可以展现出该某些趋势。因而，本文的技术允许在开发人员无法直接访问的平台(例如，开发人员未开发和/或调试该平台上的功能代码)上的粒度性能跟踪。在一些实施例中，faas系统(例如，编排器或调度器)可以使用所收集的快照数据以实现更高效的调度和分配。

附加注解与示例

示例701包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该可执行程序指令在由计算设备执行时致使该计算设备：生成与容器中的功能执行相关联的计数器值的第一快照，生成与容器中的功能执行相关联的计数器值的第二快照，以及将第一快照、第二快照、或第一快照与第二快照之间的差异中的一者或多者存储到虚拟性能监视单元(pmu)缓冲器。

示例702包括示例701的至少一种计算机可读存储介质，其中该程序指令在由该计算设备执行时致使该计算设备：经由应用编程接口(api)端点将虚拟pmu缓冲器暴露于功能、编排器、或节点管理器中的一者或多者。

共享存储器示例

一些实施例可以有利地提供用于核内消息、系统内消息、平台内消息、和/或机器消息通信的缓冲器扩充。与协作功能共处于同一核、同一系统、同一平台和/或具有共享存储器的任何执行单元内的情况相比，常规的通过http的功能间通信可涉及更多的开销。一些实施例可提供共享存储器以允许两个协作功能共享存储器段以用于复制在两个功能之间交换的数据内容。有利的是，一些实施例可以通过绕开os内核和其他http层来避免功能间通信开销。

现在转向图8a，电子处理系统810的实施例可包括处理器811、与处理器811通信耦合的存储器812、以及与处理器811和存储器812通信耦合的逻辑813，以在第一瞬态功能以及与第一瞬态功能协作的第二瞬态功能之间共享存储器812的存储器区域。在一些实施例中，逻辑813可以被进一步配置成提供用于faas平台的协作式瞬态功能(诸如第一和第二瞬态功能)之间的核内、系统内、平台内和/或机器消息通信的缓冲器扩充。在一些实施例中，逻辑813可以被配置成通过共享存储器区域在第一瞬态功能与第二瞬态功能之间交换数据。例如，逻辑813可以被配置成将所交换的数据与调用指令和返回指令中的至少一者同步。在一些实施例中，逻辑813可以位于各种组件中或与各种组件共处一地(例如，在同一管芯上)，这些组件包括处理器811、存储器812等。

上述处理器811、存储器812、逻辑813、以及系统810的其他组件中的每一者的实施例能以硬件、软件或其任何合适组合来实现。例如，硬件实现可包括诸如例如可编程逻辑阵列(pla)、场可编程门阵列(fpga)、复杂可编程逻辑器件(cpld)之类的可配置逻辑，或使用诸如例如专用集成电路(asic)、互补金属氧化物半导体(cmos)或晶体管-晶体管逻辑(ttl)技术之类的电路技术的固定功能逻辑硬件，或者其任何组合。

替代地或附加地，这些组件的全部或部分可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，随机存取存储器(ram)、只读存储器(rom)、可编程rom(prom)、固件、闪存等)中将由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种操作系统(os)适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。例如，存储器812、持久存储介质、或其他存储器可以存储一组指令，该组指令在由处理器811执行时致使系统810实现系统810的一个或多个组件、特征、或方面(例如，逻辑813、共享存储器区域、提供缓冲器扩充、交换数据等)。合适的处理器的实施例可包括通用处理器、专用处理器、cpu、gpu、控制器、微控制器、内核、执行单元等。

现在转向图8b，半导体封装装置820的实施例可包括一个或多个衬底821和耦合到一个或多个衬底821的逻辑822，其中逻辑822至少部分地在一个或多个可配置逻辑和固定功能硬件逻辑中实现。耦合到一个或多个衬底821的逻辑822可以被配置成在第一瞬态功能以及与第一瞬态功能协作的第二瞬态功能之间共享存储器区域。在一些实施例中，逻辑822可以被进一步配置成提供用于faas平台的协作式瞬态功能之间的核内、系统内和/或平台内机器消息通信的缓冲器扩充。在一些实施例中，逻辑822可以被配置成通过共享存储器区域在第一瞬态功能与第二瞬态功能之间交换数据。例如，逻辑822可以被配置成将所交换的数据与调用指令和返回指令中的至少一者同步。在一些实施例中，耦合到一个或多个衬底821的逻辑822可以包括位于一个或多个衬底821内的晶体管沟道区。

逻辑822、以及装置820的其他组件的实施例能以硬件、软件或其任何组合(至少包括部分硬件实现)来实现。例如，硬件实现可包括诸如例如pla、fpga、cpld之类的可配置逻辑、或使用诸如例如asic、cmos或ttl技术之类的电路技术的固定功能逻辑硬件、或者其任何组合。此外，这些组件的部分可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中将由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

装置820可实现方法830(图8c)的一个或多个方面或本文讨论的任何实施例。在一些实施例中，所示装置820可包括一个或多个衬底821(例如，硅、蓝宝石、砷化镓)以及耦合到衬底821的逻辑822(例如，晶体管阵列和其他集成电路/ic组件)。逻辑822可至少部分地被实现在可配置逻辑或固定功能逻辑硬件中。在一个实例中，逻辑822可包括位于(例如，嵌入)(多个)衬底821内的晶体管沟道区。因此，逻辑822与(多个)821之间的接口可以不是突变结。逻辑822还可被认为包括在(多个)衬底821的初始晶片上生长的外延层。

现在转向图8c，在多个faas功能之间共享存储器的方法830的实施例可包括：在框831分配用于第一瞬态功能的存储器区域，以及在框832在第一瞬态功能以及与第一瞬态功能协作的第二瞬态功能之间共享该存储器区域。方法830的一些实施例可进一步包括在框833提供用于faas平台的协作式瞬态功能之间的核内机器消息通信的缓冲器扩充。方法830的一些实施例可进一步包括在框833提供用于faas平台的瞬态功能之间的节点内机器消息通信的缓冲器扩充。方法830还可包括在框834通过共享存储器区域在第一瞬态功能和第二瞬态功能之间交换数据。例如，方法830可包括在框835将所交换的数据与调用指令和返回指令中的至少一者同步。

方法830的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法830的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法830可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法830可在结合下文示例814至817来描述的计算机可读介质上被实现。方法830的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

现在转向图8d，在多个faas功能之间共享存储器的方法870的实施例可包括：在框872分配用于第一瞬态功能的存储器区域，以及在框874在第一瞬态功能以及与第一瞬态功能协作的第二瞬态功能之间共享该存储器区域。方法870的一些实施例可进一步包括在框876提供用于faas平台的协作式瞬态功能之间的系统内和/或平台内机器消息通信的缓冲器扩充。方法830还可包括在框878通过共享存储器区域在第一瞬态功能和第二瞬态功能之间交换数据。例如，方法870可包括在框880将所交换的数据与调用指令和返回指令中的至少一者同步。

方法870的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法870的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法870可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法870可在结合下文示例814至817来描述的计算机可读介质上被实现。方法870的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

在一些实施例中，在位于同一机器上且使用如方法870中描述的基于存储器的传递的两个协作功能之间的数据传递不要求执行通信的进程或线程必须进入内核，且因而它们可以实现来自用户应用的数据交换。此外，新指令可以安全地在用户级执行必要的数据交换。即，由于指令可以被设计成以硬件特权(甚至高于内核特权)来操作，因而功能的执行具有将数据从一个功能的容器复制到另一功能的容器的权利。替换地，实际的复制可以用固件或用os中的协助器线程来执行，但是可以由不要求以内核模式发送和接收功能的新指令来设置移动以便激活该固件或协助器线程。

现在转向图8e，增强的faas系统840的实施例可包括两个协作的faas功能841和842(例如功能a和b)以及可被配置成促成两个faas功能841和842之间的协作的共享存储器843。一些实施例可有利地提供用于faas功能841和842之间的机器消息/json通信的缓冲器/isa扩充。某一faas架构可使用标准数据互换格式，诸如用于通过http进行功能间通信的json。在协作faas功能被调度器调度为共处于同一机器(例如核或主机)上时，功能间通信不必穿过os内核和其他http层。在一些实施例中，共享存储器843可以通过让两个功能841、842共享用于复制在两个功能841、842之间交换的数据内容的存储器段来提供一种通信方式。例如刚好在被调用方功能被调用之前，调用方功能所传递的参数可以从调用方被复制到共享存储器。在被调用方被返回时，响应/json对象内容可以从共享存储器被复制到调用方。同步可以经由调用和返回指令自然地发生。

现在转向图8f，功能后备缓冲器(flb)850的实施例可包括用于两个协作的faas功能的条目f和g。通信应当经由共享存储器(例如或内部缓冲器)还是通过常规http/内核路由来进行可以通过检查调用方对于被调用方而言是否是本地的/邻近的(例如，核内、系统内、平台内和/或具有共享存储器的执行单元)来确定，并且随后基于该检查的值进行分支以运行用于打包/复制数据的恰适代码。为了加速该检查，flb850可包括与硬件结构类似的转换后备缓冲器(tlb)，该tlb可以被用于高速缓存一起共处一处的功能的进程/lambdaid。局部性信息可以随着功能类似于页表条目那样四处移动而更新，并且当功能从主机中被移除时高速缓存中的任何驻留条目被无效。

现在转向图8g，增强的faas系统860的实施例可包括与两个或更多个服务器863、864和865通信的编排器862。功能代码f1到f9可以分布在服务器863、864和865之间，其中在f1、f4、f5、f6和f8之间存在协作。因为f4、f5和f6共处于同一服务器864上，所以一些实施例可以有利地利用服务器864上的共享存储器来促成f4、f5和f6之间的协作。一些实施例可以利用什么功能正在什么服务器上运行的基于图的表示以实现更好的箱式打包和/或局部性优化。一些实施例还可利用跨功能通信模式的基于图的表示。例如，跨节点的调用链可以作为基于图的表示被共享。

在一些实施例中，os可以将功能调用api暴露于各功能。例如，api框架可以使用用于功能调用的osapi来代替网络通信(如果可用的话)。有利的是，api框架可以提供与用于远程调用的网络相比更高效的传输。一些实施例可以通过利用128位地址来使全部的功能全局化并且使远程直接存储器访问(rdma)可实现来避免网络。

系统810(图8a)、装置820(图8b)、方法830(图8c)、faas系统840(图8d)、flb850(图8e)和/或faas系统860(图8f)的各实施例或方面/特征可以被替换为faas平台102(图1)、增强的faas系统202(图2)、faas服务器架构300(图3)、增强的faas系统(图4)、和/或增强的faas系统(图5)的全部或部分或被纳入其中。例如，各实施例的软件组件(例如，功能代码、逻辑的各方面等)可以被纳入faas软件子系统506(图5)中，并且各实施例的硬件组件(例如，共享存储器、flb、逻辑的各方面等)可以被纳入faas硬件子系统508(图5)中。

附加注解与示例

示例800包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该可执行程序指令在由计算设备执行时致使该计算设备：在第一瞬态功能以及与第一瞬态功能协作的第二瞬态功能之间共享存储器的存储器区域，利用128位地址，暴露用于第一和第二瞬态功能的功能调用接口，以及创建包括第一和第二瞬态功能的基于图的表示。

示例801包括一种电子处理系统，其包括：处理器、与该处理器通信耦合的存储器、以及与该处理器和该存储器通信耦合的逻辑，该逻辑用于在第一瞬态功能以及与第一瞬态功能协作的第二瞬态功能之间共享存储器的存储器区域。

示例802包括示例801的系统，其中该逻辑进一步用于提供用于功能即服务平台的协作式瞬态功能之间的机器消息通信的缓冲器扩充。

示例803包括示例801至802中任一者的系统，其中该逻辑进一步用于通过共享存储器区域在第一瞬态功能与第二瞬态功能之间交换数据。

示例804包括示例803的系统，其中该逻辑进一步用于将所交换的数据与调用指令和返回指令中的至少一者同步。

示例805包括一种半导体封装装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地实现在可配置逻辑和固定功能硬件逻辑中的一者或多者中，耦合至该一个或多个衬底的逻辑用于在第一瞬态功能以及与第一瞬态功能协作的第二瞬态功能之间共享存储器的存储器区域。

示例806包括示例805的装置，其中该逻辑进一步用于提供用于功能即服务平台的协作式瞬态功能之间的机器消息通信的缓冲器扩充。

示例807包括示例805至806中任一者的装置，其中该逻辑进一步用于通过共享存储器区域在第一瞬态功能与第二瞬态功能之间交换数据。

示例808包括示例807的装置，其中该逻辑进一步用于将所交换的数据与调用指令和返回指令中的至少一者同步。

示例809包括示例805至808中任一个示例的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例810包括一种共享存储器的方法，其包括：分配用于第一瞬态功能的存储器区域，以及在第一瞬态功能以及与第一瞬态功能协作的第二瞬态功能之间共享存储器的该存储器区域。

示例811包括示例810的方法，进一步包括：提供用于功能即服务平台的协作式瞬态功能之间的机器消息通信的缓冲器扩充。

示例812包括示例810至811中任一者的方法，进一步包括通过共享存储器区域在第一瞬态功能与第二瞬态功能之间交换数据。

示例813包括示例812的方法，进一步包括将所交换的数据与调用指令和返回指令中的至少一者同步。

容器推测性执行示例

一些实施例可以有利地提供推测性执行之前的容器运行。一些功能涉及长等待时间/启动，这可能使执行变慢。一些实施例可以提供执行前运行机制以在处理器/核级取得数据/指令流，并且还用于保留和/或重分配资源。有利的是，一些实施例可以减少可利用提前运行能力的优点的功能的等待时间/启动。

作为解说而非限制，提前运行可以指代允许处理器在高速缓存未命中周期期间保持(例如推测性地)执行指令而非停滞的技术。推测性执行可以被用于通过检测指令/高速缓存未命中来在它们原本会发生之前通过使用空闲执行资源来生成指令和数据流预取。可管理的成本可包括提供推测性执行支持以保留寄存器堆状态并且阻止推测性存储修改存储器。

一些faas功能可获益于执行可变长度(例如，某一很长的)等待时间操作的阻塞，这些操作诸从向数据库进行查询、调用其他faas服务等。一些实施例可提供执行前运行技术以在处理器/核级取得数据/指令流，并且还可以保留/分配资源(例如，诸如保留用于访问数据库的带宽、使可能被调用的容器/faas功能温暖、将容器/faas功能重定位到当前功能附近的位置等)。

为了在faas环境中启用此类能力，一些实施例可以提供写入时复制技术以支持处理器级的推测性执行，以及运行时例程以将外部可见的操作(例如，诸如外部功能调用、数据库更新等)替换出来而替换入用于保留/重分配资源的恰适的匹配操作。一些实施例可以利用多密钥完全存储器加密(mktme)来将密钥标记到功能。例如，一些实施例可以使用mktme来提供具有rdma的自由推测侧信道。在一些实施例中，编程人员可以通过数据结构来指示关于是否要执行推测性执行之前的运行的提示。

在一个实施例中，诸如结合图8a描述的电子处理系统被配置成提前运行以取得与faas有关的信息，并且基于取得的与faas有关的信息来阻塞一个或多个可变长度等待时间操作。在一些实施例中，该电子处理系统可以被进一步配置成基于取得的与faas有关的信息来保留和/或重分配资源。附加地或替换地，该电子处理系统可以被进一步配置成将一个或多个外部可见的操作替换出来以替换为用于保留和重分配资源中的一者或多者的对应匹配操作。在一些实施例中，各组件，诸如逻辑、处理器、存储器等，可以位于彼此中或彼此共处一处(例如，在同一管芯上)。

在另一实施例中，与图8b中例示的半导体封装装置相同或相似的半导体封装装置，可包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地在可配置逻辑和固定功能硬件逻辑中的一者或多者中实现。耦合至该一个或多个衬底的逻辑可以被配置成提前运行以取得与faas有关的信息，并且基于取得的与faas有关的信息来阻塞一个或多个可变长度等待时间操作。在一些实施例中，该逻辑可以被进一步配置成基于取得的与faas有关的信息来保留和/或重分配资源。附加地或替换地，该逻辑可以被进一步配置成将一个或多个外部可见的操作替换出来以替换为用于保留和重分配资源中的一者或多者的对应匹配操作。在一些实施例中，耦合至该一个或多个衬底的逻辑可包括位于该一个或多个衬底内的晶体管沟道区。

现在转向图9a，提供功能即服务的方法930的实施例可包括：在框931提前运行以取得与faas有关的信息，以及在框932基于取得的与faas有关的信息来阻塞一个或多个可变长度等待时间操作。方法930的一些实施例可进一步包括在框933基于取得的与faas有关的信息来保留和/或重分配资源。附加地或替换地，方法930还可包括在框934将一个或多个外部可见的操作替换出来以替换为用于保留和重分配资源中的一者或多者的对应匹配操作。

方法930的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法930的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法930可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法930可在结合下文示例931至933来描述的计算机可读介质上被实现。方法930的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

现在转向图9b，增强的faas系统910的实施例可包括通信耦合至资源管理器944的取流模块942。取流模块942可包括用于提前运行以取得要被执行的功能的与faas有关的信息的技术。资源管理器944可包括用于基于取得的与faas有关的信息来阻塞一个或多个可变长度等待时间操作的技术。在一些实施例中，资源管理器944可以被进一步配置成基于取得的与faas有关的信息来保留和/或重分配资源。附加地或替换地，资源管理器944可以被进一步配置成将一个或多个外部可见的操作替换出来以替换为用于保留和重分配资源中的一者或多者的对应匹配操作。系统940的一些实施例可以有利地提供推测性执行之前的容器运行(例如，在faas环境中)。

现在转向图9c，增强的faas系统950的实施例可包括一些faas功能的推测性执行。用户951可以使用浏览器952来显示网页954，网页954包括多个图像，例如，img1.jpg到imgn.jpg。用户951可以通过faas系统950经由图像旋转功能953来旋转网页954的一个或多个图像。faas系统950可以确定旋转一个或多个图像(例如，img1.jpg到imgn.jpg)的可能用户意图，并且可以推测性地将图像旋转到一个或多个替换取向。例如，faas系统950可以检测图像取向的使用模式/序列，并且提前启动各个旋转功能以获得更佳的用户体验和/或性能度量。推测性执行从用户角度来说可以极大地减少旋转图像的等待时间。

系统、装置、方法930(图9a)、faas系统940(图9b)、和/或faas系统950(图9c)的各实施例或方面/特征可以被替换为faas平台102(图1)、增强的faas系统202(图2)、faas服务器架构300(图3)、增强的faas系统(图4)、和/或增强的faas系统(图5)的全部或部分或被纳入其中。例如，各实施例的软件组件(例如，取流器、资源管理器、功能代码、逻辑的各方面等)可以被纳入faas软件子系统506(图5)中，并且各实施例的硬件组件(例如，各个队列/缓冲器、逻辑的各方面等)可以被纳入faas硬件子系统508(图5)中。

附加注解与示例

示例900包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该可执行程序指令在由计算设备执行时致使该计算设备：提前运行以取得至少一个功能的与faas有关的信息，基于取得的与faas有关的信息来阻塞一个或多个可变长度等待时间操作，通过多密钥完全存储器加密将密钥标记到功能，检测与图像有关的信息，以及基于检测到的与图像有关的信息来提前启动图像操作。

示例901包括一种电子处理系统，其包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，该逻辑用于提前运行从而取得至少一个功能的与faas有关的信息，以及基于取得的与faas有关的信息来阻塞一个或多个可变长度等待时间操作。

示例902包括示例901的系统，其中该逻辑进一步用于基于取得的与faas有关的信息来进行保留和重分配资源中的一者或多者。

示例903包括示例901至902中任一者的系统，其中该逻辑进一步用于将一个或多个外部可见的操作替换出来以替换成用于保留和重分配资源中的一者或多者的对应匹配操作。

示例904包括一种半导体封装装置，其包括：一个或多个衬底，以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地被实现在可配置逻辑和固定功能硬件逻辑中的一者或多者中，耦合至该一个或多个衬底的逻辑用于：提前运行以取得至少一个功能的与faas有关的信息，以及基于取得的与faas有关的信息来阻塞一个或多个可变长度等待时间操作。

示例905包括示例904的装置，其中该逻辑进一步用于基于取得的与faas有关的信息来进行保留和重分配资源中的一者或多者。

示例906包括示例904至905中任一者的装置，其中该逻辑进一步用于将一个或多个外部可见的操作替换出来以替换成用于保留和重分配资源中的一者或多者的对应匹配操作。

示例907包括示例904至906中的任一个示例的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例908包括一种提供功能即服务的方法，其包括：提前运行以取得至少一个功能的与faas有关的信息，以及基于取得的与faas有关的信息来阻塞一个或多个可变长度等待时间操作。

示例909包括示例908的方法，进一步包括基于取得的与faas有关的信息来进行保留和重分配资源中的一者或多者。

示例910包括示例908至909中任一者的方法，进一步包括将一个或多个外部可见的操作替换出来以替换成用于保留和重分配资源中的一者或多者的对应匹配操作。

平台反馈、多版本功能和异步功能示例

常规faas调用可涉及大量触发事件，包括调用功能的某一最终触发事件。在功能被调用之后，工作被分派到具有一些容器(例如，新启动的、温暖的等)的平台。但可能存在过少的资源以致于无法用于支持新调用。堆积的等待时间可能延迟功能的执行。常规触发机制按照一个方向从前因流向功能调用，这对于要在faas系统自身的能力和外部资源之间进行优化而言可能是困难的。在一些faas系统中，加速功能的启动时间增加了执行功能的等待时间。另一个问题是faas数据/动作可能难以跨分解系统而同步。全同步动作要求作出调用的功能在调用后续功能之前等待任务的完成。用于作出调用的功能的资源被捆绑着一起等待。

增强的faas系统的一些实施例可以将来自执行功能的平台的反馈提供到触发机制，该反馈指示该平台已成熟以供接下来的功能调用。一些实施例还可提供对所需资源/条件的提前通知，其中在此类资源可用或预期可用时并且在此类条件被满足时(例如，拉相对于推)从平台返回某一通知。一些实施例还可通过提供替换形式的加速功能来隐藏加速功能的启动时间，替换形式的加速功能可以在加速功能启动的同时被使用。在一些实施例中，一些功能可以被标识为是异步的以支持服务链结。有利的是，一些实施例可以避免资源饥饿，提供对资源的更佳利用，和/或在功能执行方面经历更少的等待时间(例如，或明显的等待时间)。例如，一些实施例可以在分派被链结的功能之后释放作出调用的功能(例如，使功能更原子化且更模块化)。

在一个实施例中，与结合图8a描述的相同或相似的电子处理系统，可包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，以从触发代理接收对后续功能调用的请求，以及将反馈提供给触发代理以指示对后续功能调用准备就绪。替换地或附加地，该逻辑可以被配置成提供一个或多个替换形式的加速功能，该替换形式的加速功能可以在加速功能启动的同时被使用。替换地或附加地，该逻辑可以被配置成将一个或多个功能标识为是异步的以支持服务链。在一些实施例中，该逻辑可位于各种组件中或与各种组件共处一地，这些组件包括(例如，在同一管芯上的)处理器、存储器等。

在另一实施例中，与结合图8b所描述的相同或相似的半导体封装装置，可包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地在可配置逻辑和固定功能硬件逻辑中的一者或多者中实现。耦合至该一个或多个衬底的逻辑可以被配置成从触发代理接收对后续功能调用的请求，以及将反馈提供给触发代理以指示对后续功能调用准备就绪。替换地或附加地，该逻辑可以被配置成提供一个或多个替换形式的加速功能，该替换形式的加速功能可以在加速功能启动的同时被使用。替换地或附加地，该逻辑可以被配置成将一个或多个功能标识为是异步的以支持服务链。在一些实施例中，耦合至该一个或多个衬底的逻辑可包括位于该一个或多个衬底1021内的晶体管沟道区。

现在转向图10a，提供功能即服务的方法1030的实施例可包括：在框1031从触发代理接收对后续功能调用的请求，以及在框1032将反馈提供给触发代理以指示对后续功能调用准备就绪。替换地或附加地，方法1030可包括在框1033提供一个或多个替换形式的加速功能，该替换形式的加速功能可以在加速功能启动的同时被使用。替换地或附加地，方法1030可包括在框1034将一个或多个功能标识为是异步的以支持服务链。

方法1030的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法1030的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法1030可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法1030可在结合下文示例1011至1013来描述的计算机可读介质上被实现。方法1030的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

平台反馈示例

现在转向图10b，增强的faas系统1040的实施例可包括(例如有线或无线)通信耦合至客户端1044的faas平台1042。一些实施例可以有利地提供用于断言对平台事件和回调的faas和/或硬件加速faas(afaas)动作的架构支持。硬件加速faas或afaas动作是可以在图3中示出的faas服务器300中在fpga318、加速器314、gpu、智能nic302等上执行的动作。例如，faas平台1042可包括平台管理器1046，平台管理器1046包括用于从客户端1044接收对后续功能调用的请求，以及将反馈提供给客户端1044以指示对后续功能调用准备就绪的技术。当功能被触发(例如调用)时，守护进程(daemon)例如可以由于不成熟的分派条件而造成延迟(例如，等待更长时间以获得更佳的条件、qos考量等)。不成熟的条件还可以与可能处于高需求的有限资源情景(例如，存储、加速器等)有关，并且因此可能存在访问这些资源的队列。由于各种约束，功能可能由于其在启动时花费时间过久而无法执行(例如，在5分钟之后超时)。一些实施例可以提供平台监视(例如，由平台调用器执行)和/或将功能分成各个段/片。平台管理器1046接着可以运行不要求对有限资源的访问的各个功能片，对数据进行预排队，启动虚拟功能来监视资源，以及在准备好的时候执行其余功能片。通过将功能分成各个段，客户端1044(例如消费者)可以在恰适的时间执行回调和/或暂停该功能直到资源变得可用。

一些实施例可提供两个潜在的独立但互补的能力，包括1)faas动作的平台和能力开明的提交和执行，以及2)faas动作的基于条件或事件反馈的即时执行。一些实施例可以提供消费者(例如客户端1044)引导平台提供商以及平台提供商基于各个平台、网络和功率条件提供达成动作的更具协作性和知悉性的执行方面的灵活性。

现在转向图10c，增强的faas系统1050的实施例可包括功能分割器1051、平台监视器1052、功能回调模块1053、以及功能暂停模块1054。例如，各个平台条件可以由平台监视器1052监视，并且在用于执行动作的资源可用且平台满足如接下来描述的各种其他细微条件时，接着可以执行动作的实际触发。细微平台条件的示例是到数据的距离。例如，如果数据集驻留在机器或存储位置中，并且需要该数据集的功能在不同的机器上运行，该功能对数据集的访问必须通过一个或多个网络或存储链路，这使得访问与数据集与功能在同一机器上的情形相比慢得多(例如，它们需要相当大量的盘或网络io操作)，则此类细微平台条件未被满足。元调度器可以发起数据迁移操作以便满足此类“到数据的距离”条件，并且一旦足够的数据已经迁移，动作就可以继续。替换地，如果功能需要被推送得更靠近数据所在的位置(例如，在远程节点上)，则该细微条件改变为在数据附近“具有充分的计算资源”。细微条件的另一示例是成本。例如，可能期望功能仅在功能能够以较低成本被执行的情况下才被触发(例如，假定用于触发功能的所有其他条件都已被满足)。例如在平台在功率、cpu周期、存储器带宽等方面具有充分的剩余容量的情况下，这可能为真，以使得功能能够被给予最大努力处置并且预期在某一自由但有限的等待时间内完成。换言之，这一办法构想了在断言满足了有效性、效率以及甚至安全性的各种直接和间接测量之际对功能的触发和/或实际分派(例如，安全准则的示例可以是无敏感服务在平台上运行，以便准许运行对于安全性而言属于灰名单的动作)。

对于afaas，资源可用性也可以是此类平台条件，尤其在afaas被用于进行人工智能(ai)模型的低密度后台训练的情况下。通过这么做，目标可以是达成功能的更具确定性的执行，尤其在功能执行所处的条件本身是第二触发事件时(例如，在第一触发事件可以仅仅是达到“所有基于逻辑状态或时间触发的前体已经被满足”的效果的情况下)。实际上，这一技术可以显式地且系统地将功能的执行链接到正确资源的可用性以及投射在功能上的需求。

功能回调模块1053可以在接收和处理该模块通过来自平台基础设施的反馈所请求的信息之际允许消费者(例如，或充当消费者代理的软件代理)捆绑faas活动的实际提交。例如，回调模块1053可以利用某些作为总是准备好(例如“预触发”)来被处理的元功能，以使得回调自然地激活控制器处或调用器处的消费者代理。这一代理提供了对消费者期望即时地、且处于刚好符合的平台条件下派发的功能的所需触发。

有利的是，faas系统中的监视和/或回调技术的一些实施例可以支持“自带能力”(byoc)办法以达成更丰富的协作，其中消费者可以在csp的默许之下预留一些资源(例如，通过提前单独地请求一些资源来显式地获得它们)同时等待csp处较稀缺的其他资源以达成开明的分派。例如，一些转换服务可以在调用faas来执行转换之前在它们自身的资源上使一切准备就绪。深度神经网络(dnn)对于faas平台而言可能过大，因此消费者可以在csp处的其自身的预付资源上执行dnn部分，并且接着使用csp的faas平台来执行预期功能的剩余部分。

系统、装置、方法1030(图10a)、faas系统1040(图10b)、和/或faas系统1050(图10c)的各实施例或方面/特征可以被替换为faas平台102(图1)、增强的faas系统202(图2)、faas服务器架构300(图3)、增强的faas系统(图4)、和/或增强的faas系统(图5)的全部或部分或被纳入其中。例如，各实施例的软件组件(例如，平台管理器、功能分割器、平台监视器、回调特征、暂停特征、功能代码、逻辑的各方面等)可以被纳入faas软件子系统506(图5)中，并且各实施例的硬件组件(例如，各个队列/缓冲器、逻辑的各方面等)可以被纳入faas硬件子系统508(图5)中。

多版本功能示例

现在转向图11a，功能1110的实施例可包括用于实例化的多个选项(例如，选项1到n)。一些实施例可以有利地提供同一功能1110的多个版本，并且进一步提供同一功能1110的多个加速版本。同一功能1110的多个版本，包括同一功能1110的多个加速版本，可以在它们的实例化所需的时间或资源方面，以及在功能1110需要被执行时执行或运行实例化所花费的时间方面彼此不同。一些实施例将这些多个版本作为按照渐进式方式被发起的多个租户来提供。一些容器(例如，使用加速器或利用核的容器，其中核根据机器而不同)可能要等一会才启动。软件功能可以提供低等待时间启动，但是较长等待时间执行。硬件功能可以提供长等待时间启动，但是短等待时间执行。在一些实施例中，功能1110可包括多个选项(例如实例化)，取决于各种因素(例如，调用器要求、faas平台条件等)这些选项中的一者可以被选择用于执行。

现在转向图11b，增强的faas系统1120的实施例可以支持具有功能b的多个版本的代码块a。例如，代码块a的调用器可以标识功能b的不同版本，包括最小名单加速器版本bm、高加速器版本bh、以及无加速器版本bs。如果容器被启动以用于加速器(例如，最小名单加速器bm)，则一些实施例可以将b功能的每一版本转移到该容器。一些实施例可以基于功能b的逐渐减少的新到达数目而使加速容器降级(例如，释放高加速器bh并且使最小名单版本bm温暖，或者转移到软件/非加速器版本bs)。一些实施例可以将多个功能版本与数据向功能b的物理位置附近的预取相组合。

一些实施例可以有利地在启动新加速功能之际按照隐藏预期的并非微不足道的启动等待时间的方式在多租户情景中执行加速功能。对于在通用cpu上运行的调用器，调用的目标可以与某一功能相对应，基于该功能的初始化器或主机cpu的代码是代码块a，并且加速功能可以与功能b相对应。在a接收到控制之际，b可能已经在加速器上被初始化，或者b可能需要被映像到加速器上。

一般来说，bh的初始化可能花费几毫秒至几十毫秒。例如，fpga资源可以在多个使用活跃、空闲、以及被请求的(例如排队的)功能之间进行仲裁。如果bh不是活跃的，则可能花费一些时间来分配用于bh的资源，从近的或远的存储器中取得用于bh的比特流，并且接着激活(例如启动)该比特流。在用于bh的资源被减少并且bh被回收之前，一旦被激活，用于bh的比特流就可以被保持活跃达某一时间，以均摊在bh被保持其周围的许多占空比上启动bh的成本。为了隐藏这一等待时间，一些实施例可以支持bh的多个版本，包括例如两个附加替换形式bm和bs，其中bm可以与花费非常少的时间来启动但可能花费较长时间来执行的bh的最小加速版本相对应(例如，因为它在时间上而非在空间上执行循环)，并且其中bs可以与b的软件(例如cpu)版本相对应(例如，可以比bh在功率和性能效率上低得多、但是如果bs是温暖的则可以几乎立即启动的b的非加速版本)。

现在转向图11c，提供功能即服务的方法1130的实施例可包括：在框1131确定功能的全加速版本(例如，在在高加速器硬件上操作的容器中执行的功能)是否活跃，并且如果是，则在框1132使用该全加速版本。否则，方法1130可以在框1133确定功能的部分加速版本(例如，在在最小名单加速器硬件上操作的容器中执行的功能)是否活跃，并且如果是，则在框1134使用该部分加速版本。否则，方法1130可以在框1135使用功能的非加速版本。取决于消费者需要/平台条件，方法1130可以进一步包括在框1136推测性地启动功能的全加速版本或部分加速版本(例如，并且在其变为活跃时切换到该版本)。

换言之，代码块a可以使用bh，其中bh已经是活跃的(例如，b的最快且最高效的执行)，且没有用于bh的设置时间；否则如果bm已经是活跃的(例如，没有设置时间但有较长历时的执行)，则a可以使用bm；或者如果bh或bm都不活跃，则a可以使用bs，在bh或bm活跃之后a可以启动bm或启动bh，并且接着根据期望的等待时间-性能-面积-功率折衷来使用所启动的bm或bs。

一些实施例可以首先为已知(例如通过历史概况分析)是频繁的那些加速功能预启动bm版本。对于非频繁的加速功能，一些实施例可以按需启动这些最小版本，但是在bm或bs尚未被启动时最初使用软件版本bs。如果对bs或bm的需求在最近的时间窗口中超过某一阈值，则一些实施例可以启动加速功能bh并且继续将bs或bm用于对b的请求，直到bh被完全激活。

一些实施例还可收集用于每一被启动的b的移动窗口利用和成本度量。如果所收集的信息落在阈值以下，或者对其他功能的需求增加，则一些实施例可以发起bh的回收，如果bm符合要求，则响应于对执行b的新请求回收用于bh的资源但原地启动bm。相反，如果对b的需求从阈值以下到超过阈值，则一些实施例可以发起bh的启动，并且在bh已经被激活之后在bm活跃的情况下回收bm。

在选择用于启动bm或bh的阈值方面(例如，在bs或bm的利用分别升高时)以及在选择用于回收bh或bm的阈值方面(例如，在bh和bm的利用分别降低时)，一些实施例可以将由afaas控制服务动态提供的服务水平协议(sla)输入纳入考虑。如果未提供sla输入，则这些阈值可以基于对b的请求的达到率(例如，或达到率的移动窗口均值)被启发式地且动态地设置。

一些实施例可以利用对按照bh的硬件成本进行标准化的占空比(利用)的持续监视来达成两个目标：1)决定要使hb保持活跃多久，以及2)累积历史信息，以使得可以通过将历史频率和活跃利用历时用作指引来加速bh的将来激活。贪婪箱式打包试探法可以被用于确定用于从功能的bs切换到bm切换到bh版本的阈值。这些统计数据可以通过使用用于bh的收尾来更新，并且可以被用于更新存储器中的统计数据，代码块a的将来激活使用存储器中的统计数据以在bs、bm和bh之间进行选择。

功能1110(图11a)、faas系统1120(图11b)、和/或方法1130(图11c)的各实施例或方面/特征可以被替换为faas平台102(图1)、增强的faas系统202(图2)、faas服务器架构300(图3)、增强的faas系统(图4)、和/或增强的faas系统(图5)的全部或部分或被纳入其中。例如，各实施例的软件组件(例如，多版本功能代码、逻辑的各方面等)可以被纳入faas软件子系统506(图5)中，并且各实施例的硬件组件(例如，监视、逻辑的各方面等)可以被纳入faas硬件子系统508(图5)中。

异步功能示例

现在转向图12，增强的faas系统1210的实施例可包括：具有队列1214的调度器1212，队列1214包括事件队列1218、功能队列1216、触发事件队列1220等。一些实施例可以有利地提供分布式动作之间的高效同步。通过中介动作被链接的链结功能(例如，功能x需要调用动作来存储要被功能y使用的数据)可能导致若干调用。考虑动作x，动作x在它能够认为其自身已经完成之前需要执行网络或存储操作p，并且触发要处理通过以上操作p在存储区域中传递或填充的数据的另一动作y。在常规faas系统中，例如，动作x必须等待网络或存储操作p来完成填充并且接着调用或触发动作y。调度器1212可能需要等一会，在等待时间期间资源正被动作x使用。增强的faas解决方案的一些实施例可以有利地使动作x触发网络或存储操作p并且修改网络或存储操作p，以使得网络或存储操作p的完成用于触发动作y，从而动作x可以在网络或存储操作p完成之前被丢弃以释放动作x所消耗的资源。一些实施例还可允许更有趣的并行化(例如，模块化设计)，因为根(例如父功能)不必等待，从而由完成触发的其他功能可以开始执行。一些实施例可以由硬件队列管理器(hqm)实现。

许多分布式动作需要被同步，即便仅仅满足出于持久性提交的或出于可见性传递的状态通过可串行化的操作序列被更新的要求。因而，例如，时间不应当表现为按照这些操作的结果被记录在耐用介质上或从第三方观察到的方式往回移动。然而，在一些情形中，进程的分布式系统中采用的办法可能过于保守。例如，即便在被采用的进程已经是数据并行的(例如，它们在数据的不相交分区上操作)时，所有代理也可以穿过屏障继续，诸如在两阶段锁定中。对于需要跨一组协调节点执行的低等待时间faas动作，此类开销过于昂贵并且它们会引入不必要的延迟。

因为实际协调中的部分或大部分可能需要在出于持久性或通信来更新状态的情况下发生，所以增强的faas解决方案的一些实施例可以扩充结构和/或存储接口以支持用于通信和存储(例如，作为存储功能或作为网络功能)的各个有效载荷的异步提交，以使得对任何给定范围的数据的更新按照全局一致的时间顺序来执行。相应地，如果两个操作x和y的依赖性被链结，从而x对共享盘上的数据块执行异步更新并且x的完成触发y(例如，其中y可以消耗x作出的更新(写之后读或即raw依赖性)或盖写x作出的更新(写之后写或即waw依赖性))，则“存储faas动作”的链结的一些实施例可以避免违反所要求的排序依赖性。一些实施例可以将存储动作自身抽象为经链结的faas动作。

作为解释而非限制，分布式功能可以与分布式进程不同，因为功能可以遵循对共享数据的关闭到开放或捕获到释放的一致性模型(例如，因为功能可能不具有超过它们的有限历时的会话状态的任何概念或运行直到完成模型)。代替动作x需要与动作x同步地执行网络或存储操作p，在用信号通知动作x的完成并且触发动作y(例如，被表示为[x,p]＝>y)之前，在一些实施例中，一个功能x可以完成，接着执行(例如触发)经链结的动作p(例如，存储、网络等)，并且在p被调度和执行时，指定p的完成可以触发功能y(例如，被表示为x＝>[p＝>y])。

例如，功能队列1216可以包含要被执行的功能的队列。功能y(或功能y的某种指示)可以被存储在功能队列1216中，例如作为第一功能。事件队列1218可以包括执行触发事件的不同事件，诸如“在第一事件发生(例如，网络或存储操作p的完成)时，执行触发事件队列1220的第一触发事件”。触发事件队列1220可以存储用于使功能队列1216的一个或多个功能执行的各个触发事件。触发事件队列1220的第一触发事件可包括触发来自功能队列1216的第一功能(例如，功能y)。因而，在网络或存储操作p完成时，系统可以根据事件队列1218确定第一事件已经发生(例如，网络或存储操作p的完成)以致使来自触发事件队列1220的第一触发事件的执行以执行。第一触发事件接着可以致使来自功能队列1216的一个或多个功能(例如功能y)执行。

常规序列[x,p]＝>y要求功能x在引退之前同步地执行更新动作p(例如，等待p)，从而增大了等待时间并且可能引起缩放瓶颈(例如，在x需要争用各个锁和资源来执行p的情况下)。y本身可能与x有关。例如，y可以是x的延续，并且要求作为执行p的结果而对其可用的一些凭证。作为一个示例，x可以是处理某一相机馈送的图像处理任务，p可以是更新图像数据库的任务，而y可以是需要处理最近的更新以查看其是否包含特定的目标对象或图案的任务。在一些实施例中，任务p可以被认为是与x有关的“即发即弃”(fireandforget)任务，以使得被分配给x的资源在p被启动之后可以被释放。

在一些实施例中，在分布式系统中对于此类同步和协调捕获和释放锁并且执行两阶段事务可以由用于高性能结构和存储操作(例如，智能nic、智能卡等)的异步命令排队技术代替。这对于“机架规模设计”或即rsd架构而言可能特别有用，其中经池化的存储和经池化的存储器可以被不同的执行引擎按照共享、扁平访问的范式来使用，以使得基于硬件的排队机制可以避免对锁、条件等的需要，并且同时避免对更高级的软件协议的需要(例如，读取器-写入器锁管理、死锁检测和解决等)。一些实施例可以利用类似于hqm的技术。例如，任务可以被委托给hqm以管理任务的执行。

系统1210(图12)的各实施例或方面/特征可以被替换为faas平台102(图1)、增强的faas系统202(图2)、faas服务器架构300(图3)、增强的faas系统(图4)和/或增强的faas系统(图5)的全部或部分或被纳入其中。例如，各实施例的软件组件(例如，调度器、功能代码、逻辑的各方面等)可以被纳入faas软件子系统506(图5)中，并且各实施例的硬件组件(例如，hqm、逻辑的各方面等)可以被纳入faas硬件子系统508(图5)中。

附加注解与示例

示例1200包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该可执行程序指令在由计算设备执行时致使该计算设备：从触发代理接收对后续功能调用的请求，将反馈提供给触发代理以指示对后续功能调用准备就绪，提供多租户加速功能的渐进式多版本发起，在分布式动作之间提供同步，以及在准则被满足时触发后续功能调用。

示例1201包括一种电子处理系统，其包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，该逻辑用于从触发代理接收对后续功能调用的请求，以及将反馈提供给触发代理以指示对后续功能调用准备就绪。

示例1202包括示例1201的系统，其中该逻辑进一步用于提供一个或多个替换形式的加速功能，该一个或多个替换形式的加速功能可以在加速功能启动的同时被使用。

示例1203包括示例1201至1202中任一者的系统，其中该逻辑进一步用于将一个或多个功能标识为是异步的以支持服务链。

示例1204包括一种半导体封装装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地在可配置逻辑和固定功能硬件逻辑中的一者或多者中实现，耦合至该一个或多个衬底的逻辑用于从触发代理接收对后续功能调用的请求，以及将反馈提供给触发代理以指示对后续功能调用准备就绪。

示例1205包括示例1204的装置，其中该逻辑进一步用于提供一个或多个替换形式的加速功能，该一个或多个替换形式的加速功能可以在加速功能启动的同时被使用。

示例1206包括示例1204至1205中任一者的装置，其中该逻辑进一步用于将一个或多个功能标识为是异步的以支持服务链。

示例1207包括如示例1204至1206中任一者的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例1208包括一种提供功能即服务的方法，其包括：从触发代理接收对后续功能调用的请求，以及将反馈提供给触发代理以指示对后续功能调用准备就绪。

示例1209包括示例1208的方法，进一步包括提供一个或多个替换形式的加速功能，该一个或多个替换形式的加速功能可以在加速功能启动的同时被使用。

示例1210包括示例1208至1209中任一者的方法，进一步包括将一个或多个功能标识为是异步的以支持服务链。

用于faas的性能增强的计算架构

无服务器计算可以允许faas和非faas功能在同一计算节点上执行。例如，类似于超线程那样将大量独立faas功能合并到正常云应用(例如，非faas功能)之间的空隙(空闲时段)中是可能的。空隙可以是在任何情形中无法由正常云应用填充的间隙。超线程可以通过附加线程来利用通过仅仅每核一个线程未被完全锻炼的空闲微架构资源。

因此，faas和非faas功能可以被合并到多租赁中以并发地在例如同一计算节点(例如，服务器或处理器核)上操作。在此类多租赁情景中，嘈杂邻居问题可能存在，其中云服务提供商(csp)共同租户独占资源(例如，带宽、盘i/o、cpu)，这可能负面地影响其他共同租户的性能。例如，非faas功能可能吸收并非所有时间都完全由faas功能订阅的资源带宽，并且反之亦然。这导致跨共同租户的不均匀的云网络性能，并且增加了faas功能执行的等待时间，或者降低了非faas共同租户的性能。新的嘈杂邻居问题可能定性地来说是唯一的，因为它关心资源在每一计算节点(例如，在处理器核级别)内的高效、自适应、精细粒度且公平的共享，不像在当前现有解决方案中在虚拟机或容器级别指派或保留资源(诸如高速缓存容量、存储器带宽、或处理器调度优先级)的其他设计那样。

以下描述的各实施例可以调度每一faas功能和非faas功能以避免在这些合并所代表的高得多的多租赁级别下的嘈杂邻居问题。这么做可能减少由等待引起的等待时间或使其稳定，并且降低由于超时错误引起的功能故障，并且控制执行性能方面的可变性。此外，一些实施例可以增强资源分发。例如，功能可以被提供给具有专用硬件加速器的节点以增强功能的执行。

一些实施例可以通过经排定优先级的调度来提供核执行资源在多个硬件线程之间的有范围的分配。经排定优先级的调度可以调度具有不冲突的需求简档的功能以用于实现共享核上的同时多线程(smt)执行(例如，smt4、smt8等)，以使得每一功能接收对该功能最敏感的至少那些资源的公平使用。通过这么做，功能间资源冲突或嘈杂邻居问题可以被避免。因而，一些实施例可包括在smt(例如，smt2、smt4)期间核执行资源的高效且敏捷、短历时且精细定界的分配所需的各方法和工具以及反馈机制。

转向图13a，例示了减少资源争用的用于faas的性能增强的计算架构1300。如下文所描述的，服务器1302可以通过分发第一到第三功能1312、1314、1316以允许第一到第三功能1312、1314、1316具有足够用于执行的第一到第三资源分配1326、1328、1330来减少资源争用。此外，在一些实施例中，正在第一到第三计算节点1304a-1304c上执行的第四到第六功能1318、1320、1322可以具有第一到第三资源的分配量，该分配量不损害第一到第三功能1312、1314、1316对第一到第三资源的访问。

最初，效率增强的服务器1302可以从基于事件的触发设备或仅仅是触发设备1306、1308、1310(例如，各个计算设备)接收对第一到第三功能1312、1314、1316(例如，faas功能)的请求。对第一到第三功能1312、1314、1316的请求可以由在触发设备1306、1308、1310上运行的应用调用。服务器1302可以确定第一到第三功能1312、1314、1316的敏感资源。例如，第一功能1312可以要求对第一资源的访问以进行执行，第二功能1314可以要求对第二资源的访问以进行执行，并且第三功能1316可以要求对第三资源的访问以进行执行。第一到第三资源可以是第一到第三功能1312、1314、1316在执行期间要求的任何类型的计算资源(例如，硬件资源、硬件加速器、带宽、算术逻辑单元、功率、频率等)，并且可以彼此不同。

服务器1302可以指导硬件资源分配，以使得第一到第三功能1312、1314、1316中的每一者接收对对于执行而言敏感的至少第一到第三资源的公平使用。详细来说，服务器1302可以调度第一到第三功能1312、1314、1316在不同定时在各个计算节点1304a-1304c上执行，以使得第一到第三功能1312、1314、1316能够在没有资源争用的情况下访问第一到第三资源。例如，为了避免资源争用，服务器1302可以将第一功能1312分发到第一计算节点1304a，以使得第一功能1312具有足够用于执行的第一资源分配1326。服务器1302可以将第二功能1314分发到第三计算节点1304c，以使得第二功能1314具有足够用于执行的第二资源分配1328。服务器1302可以将第三功能1316分发到第二计算节点1304b，以使得第三功能1316具有足够用于执行的第三资源分配1330。

在执行之前，服务器1302可以推测性地确定第一到第三功能1312、1314、1316需要的第一到第三资源。例如，服务器1302可以通过分析相关联的实现(例如，相似或相同的功能的源代码、转码、历史要求等)来确定第一到第三功能1312、1314、1316的敏感资源。因而，服务器1302可以标识功能需要的所要求的资源分配，和/或功能需要的资源类型，并且将此类资源标记为敏感资源。资源可包括功耗、固件要求、硬件要求(例如，带宽需求、加速器、cpu指令取得中的可用资源的数目或分数、tlb、分支目标缓冲器(btb)、保留站、操作端口(诸如算术逻辑单元(alu))等)或时钟频率要求中的一者或多者。还可以针对过度分配来保留资源，例如，不准许cpu核进入睿频(turbo)执行，在不同的多租户条件下控制性能的可变性。

在一些实施例中，服务器1302可以确定第一到第三功能1312、1314、1316中的每一者需要的一个或多个资源分配是否高于阈值。如果是，则服务器1302可以将该一个或多个资源标记为敏感资源。该阈值可以与第一到第三计算节点1304a-1304c处的平均历史资源可用性相对应。该阈值还可以被设置为一个或多个计算节点1304a-1304c中的每一者处的当前资源可用性。

服务器1302可基于推测性地确定的第一到第三资源来进一步调度第一到第三功能1312、1314、1316在计算节点1304a-1304c中的不同节点上执行和/或在不同定时执行以避免资源冲突。服务器1302因此可以减少等待时间并且增强第一到第三功能1312、1314、1316的完成率。

例如，第一功能1312可以执行存储器带宽密集的功能，并且因此第一资源(例如，敏感资源)是高带宽资源。第二功能1314可以执行alu计算密集的功能，并且因此第二资源(例如敏感资源)可以是alu资源。第三功能1316可包括功率密集的操作，并且因此第三资源(例如敏感资源)可以是高功率。

如上所提及的，服务器1302可以从触发设备1306、1308、1310接收请求以执行第一到第三功能1312、1314、1316，并且将第一到第三功能1312、1314、1316分发到计算节点1304a-1304c中的各个计算节点以避免资源争用。在一些实施例中，服务器1302可能已经调用了在计算节点1304a-1304c处执行的第四到第六功能1318、1320、1322(例如，非faas功能)。服务器1302可以通过参考第四到第六功能1318、1320、1322的第一到第三资源分配1332、1334、1336来标识第一到第三资源正被第四到第六功能1318、1320、1322在第一到第三计算节点1304a-1304c中的各个计算节点处广泛利用。

服务器1302可以将第一功能1312分发到第一计算节点1304a以避免资源争用。详细来说，第一功能1312需要的第一资源与第六功能1322需要的第三资源不同，并且因此避免第一功能1312与第六功能1322之间的资源争用。作为对比，如果第一功能1312被提供给第三计算节点1304c，则可能存在资源争用，因为第一功能1312和第四功能1318两者均要求第一资源作为敏感资源。

如上所解释的，第一功能1312和第四功能1318要求高分配的第一资源，而高分配可能超过第一资源在第三计算节点1304c上的可用性。例如，尽管第一功能1312可以能够以受限的量访问第一节点1304c处的第一资源，但是第一功能1312可能不具有对第一资源的充分访问以完成执行，因为第一资源已经通过第一资源分配1332被大量地分配给第四功能1318。同样地，第三功能1316被提供给第二计算节点1304b，并且第二功能1314可以被提供给第三计算节点1304c。

在一些实施例中，服务器1302可以确定第六功能1322正在利用第一计算节点1304a处的第一资源。在此类场景中，服务器1302可以确定第一功能1312是否将具有对第一资源的足够访问以完成执行。例如，如果第六功能1322仅被分配了少量的第一资源和/或对第一资源的少量访问，则第一功能1312可能仍然接收到将促成执行的第一资源的分配。

因而，服务器1302可以基于资源的可用性来确定功能是否可以访问敏感资源。例如，服务器1302可以遵循以下的等式1300来确定计算节点处的总可用分配：

总可用分配＝总潜在分配-(多个)现有分配

等式1300

在以上的等式1300中，总潜在分配是敏感资源在计算节点处的总潜在分配，而现有分配是敏感资源在计算节点处的当前分配，例如到其他功能的分配。服务器1302可以遵循以下的等式1301来确定是否存在敏感资源的足够分配：

敏感资源要求≤总可用分配

等式1301

敏感资源要求是功能的敏感资源要求。如果上式为真，则的确存在足够分配。即，如果敏感资源要求少于或等于敏感资源在计算节点处的总可用分配，则的确存在在计算节点处完成功能执行的足够分配。

在一些实施例中，服务器1302可以减少给第四到第六功能1318、1320、1322的第一到第三资源分配1332、1334、1336，并且将那些第一到第三资源分配给第一到第三功能1312、1314、1316，以使得敏感资源被均等地分发。例如，在一些实施例中，服务器1302可以将第一功能1312分发到第三计算节点1304c而非分发到第一计算节点1304a。第一功能1312和第四功能1318两者均要求第一资源作为敏感资源，并且因此可能存在资源争用。为了减少资源争用，服务器1302可以减少给第四功能1318的第一资源分配1332，并且增加给第一功能1312的第一资源分配1326。这么做可以建立第一资源在第四功能1318与第一功能1312之间的均等分配。

在一些实施例中，服务器1302可以调度第一到第三功能1312、1314、1316的定时以避免资源争用。例如，在一些实施例中，服务器1302可以将第一功能1312提供到第三计算节点1304c。如上所述，第一功能1312和第四功能1318两者均要求第一资源作为敏感资源，并且因此可能存在资源争用。为了避免资源争用，服务器1302可以在第四功能1318已经完成执行之后调度第一功能1312在第三计算节点1304c上执行。这么做可以避免第一资源在第一功能1312和第四功能1318之间的资源争用。

在一些实施例中，服务器1302可以确定硬件加速器和/或fpga可以增强功能1312、1314、1316中的一者的执行。服务器1302可以相应地调度功能1312、1314、1316中的一者来访问硬件加速器。

在一些实施例中，计算节点1304a-1304c可以是处理器核、计算设备或服务器。在一些实施例中，触发设备1306、1308、1310可以调用在远程服务器(未例示)上运行的应用，该应用进而向服务器1302提供对功能1312、1314、1316的请求。在一些实施例中，服务器1302可以调用功能1312、1314、1316。触发设备1306、1308、1310可包括例如膝上型计算机、移动设备、服务器、台式机等。在一些实施例中，服务器1302可包括第一到第三计算节点1304a-1304c。此外，在一些实施例中，服务器1302可包括实现以上描述的各方面的图4的增强的faas系统400，诸如编排器404。

图13b例示了增强的调度过程1338，其用于可以由图13a的服务器1302实现的更公平的箱式打包。在当前示例中，用于功能0和功能1中的每一者的带1和带2可以被分配硬件资源。例如，带1可以表示硬件加速器资源，而带2可以表示被分配的处理器核资源。例如，在功能0和功能1在同一时间在同一计算节点上运行的情况下，服务器1302可以推测性地分析功能0和功能1以标识分配给功能0和功能1的预测的每周期指令(ipc)资源1340、1342。功能1可以是例如非faas功能，而功能0可以是faas功能。如上所述，功能1相对于功能0可以被分配不公平得高的量的资源1340、1342(例如，被分配的硬件资源)例如，如果功能1在功能0之前开始操作，则功能1可具有不公平的资源分配。

因此，功能0和功能1的调度可以被修改，如箭头1344所例示的，以实现更公平的箱式打包，和/或在不同时间被调度和/或被调度在不同节点处和/或硬件资源可以被重分发以建立较高ipc所要求的硬件资源之间的公平性(例如，均等的量)。因而，功能0可以被分配资源1346的量(例如，被分配的硬件资源)以达成与被分配给功能1的资源1348的量(例如，被分配的硬件资源)所达成的ipc相等的ipc。尽管未例示，但功率和频率分配也可以通过修改在功能0与功能1之间被均匀地分配。

图13c示出了在csp环境中调度功能的方法1350，并且该方法可以由图13a的服务器1302和/或图4的增强的faas系统400(诸如编排器404)执行。方法1350可被实现在一个或多个模块中作为被存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法1350中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框1352可包括为多个功能中的每一相应功能确定执行该相应功能所要求的一个或多个敏感资源。所例示的处理框1354可包括确定第一功能的一个或多个敏感资源与第二功能的一个或多个敏感资源之间的资源冲突。所例示的处理框1356可包括调度第一或第二功能中的一者或多者以避免资源冲突。例如，所例示的处理框1356可包括调度第一或第二功能中的一者或多者以在完全不交叠的时间在同一节点上执行，在彼此不同的节点上执行和/或将一个功能的资源分配重分发到另一功能，以建立公平性并且维持服务质量。所例示的处理框1358可包括将一个或多个敏感资源调度到第一和第二功能以分别达成针对第一功能和第二功能的目标性能收益。例如，所例示的处理框1358可包括将敏感资源分配给第一和第二功能。尽管未例示，但方法1350可包括确定第一功能的一个或多个敏感资源与第三功能的一个或多个敏感资源之间缺少资源冲突。方法1350可包括基于该缺少资源冲突来调度第一和第三功能在交叠的时间在同一节点上执行。

方法1350可增强csp环境的效率和操作。例如，方法1350可以减少等待时间并且增强功能的完成率。

附加注解与示例

示例1300包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：为多个功能中的每一相应功能确定执行该相应功能所要求的一个或多个敏感资源，确定多个功能中的第一功能的一个或多个敏感资源与多个功能中的第二功能的一个或多个敏感资源之间的资源冲突，调度第一功能或第二功能中的一者或多者以避免资源冲突，调度第一功能和第二功能在不同时间执行，调度第一功能和第二功能在不同计算节点上执行，确定第一功能的一个或多个敏感资源与多个功能中的第三功能的一个或多个敏感资源之间缺少资源冲突，调度第一功能和第三功能在交叠的时间在同一节点上执行，并且调度对于第一功能和第二功能敏感的资源中的一个或多个以分别达成针对第一功能和第二功能的目标性能收益。

示例1301包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：为多个功能中的每一相应功能确定执行该相应功能所要求的一个或多个敏感资源，确定多个功能中的第一功能的一个或多个敏感资源与多个功能中的第二功能的一个或多个敏感资源之间的资源冲突，以及调度第一功能或第二功能中的一者或多者以避免资源冲突。

示例1302包括示例1301的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备调度第一功能和第二功能调度在不同时间执行。

示例1303包括示例1301的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备调度第一功能和第二功能调度在不同计算节点上执行。

示例1304包括示例1301的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定第一功能的一个或多个敏感资源与多个功能中的第三功能的一个或多个敏感资源之间缺少资源冲突，以及调度第一功能和第三功能在交叠的时间在同一节点上执行。

示例1305包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：为多个功能中的每一相应功能确定执行该相应功能所要求的一个或多个敏感资源，确定多个功能中的第一功能的一个或多个敏感资源与多个功能中的第二功能的一个或多个敏感资源之间的资源冲突，以及调度对第一功能和第二功能敏感的资源中的一个或多个以分别达成针对第一功能和第二功能的目标性能收益。

用于faas的增强的功能执行

图14a和14b例示了根据一些实施例的增强的功能执行序列1400。此类示例可以由图13a的服务器1302(例如第一到第三计算节点1304a-1304c中的一者或多者)和/或图4的增强的faas系统400(诸如编排器404)来实现。更具体地，功能调用1402可以请求功能1404以进行执行。功能调用1402在faas上下文中也可以被称为“触发事件”。功能1404可以是无服务器功能(例如，单个faas功能)。功能1404可以被视为可以按某一顺序执行的内部操作集合。操作可以是功能1404内模块的执行，其实现全部功能的一部分。例如，假定功能1404要根据一组条件从数据库表中选择某一数目的元组，并且接着需要对结果进行排序按照期望顺序产生输出或者从经排序的输出中进一步再选择。在该示例中，选择和排序是功能1404内部的两个操作。内部操作可以被称为“小功能”。

分解过程1406可以通过例如转码或对关于哪些模块从功能1404的代码主体被调用的静态分析来将功能1404分解成一系列小功能1408a-1408e，而非将功能1404作为原子单元来对待，并且如所呈现地执行功能1404。分解过程1406可以由编程人员、由云服务提供商来指定，和/或可以由第三方创作的优化工具链来实现。分解过程1406和分解过程1406的操作可以进一步由编程人员或云服务提供商提供的选项、提示、指令等来控制。小功能1408a-1408c中的一者或多者可以可任选地由用户实现并且被指定到过程1406。与功能不同，小功能1408a-1408e可以彼此共享不同级别的状态以实现高效的计算和协调。个体小功能1408a-1408e可经历个体调度和执行过程1410以减少等待时间并且更高效地管理资源。详细来说，小功能1408a-1408e中的一些小功能可以并发地执行以减少等待时间。此外，如果小功能1408a-1408e中的特定小功能要求诸如专用硬件(例如加速器或fpga)或固件之类的资源来执行，则可能延迟小功能1408a-1408e中的该特定小功能的执行，直到专用硬件变为可用，以增强资源利用和调度。

如所例示的，功能1404可以被分解成由小功能1408a-1408e组成的依赖图1414，其中依赖图1414指示小功能1408a-1408e的执行顺序。在依赖图1414中，小功能1408a可以首先执行。小功能1408b、1408c可基于来自小功能1408a的信息来执行，并且并发地执行。小功能1408d可以在小功能1408b、1408c之后且基于来自小功能1408b、1408c两者的信息来执行。小功能1408e可以基于来自小功能1408d的信息在小功能1408d之后执行，并且完成功能1404的执行。

调度和执行过程1410可以基于依赖图1414来操作以单独地调度小功能1408a-1408e中的每一者。例如，基于依赖图1414，小功能1408a-1408e之间的互连是清楚的。因而，调度和执行过程1410可以基于依赖图1414的依赖互连来确定是要并发地调度(并行地)还是要串行地调度(一个接着一个)小功能1408a-1408e。

如图14b的调度图1416中所例示的，小功能1408a-1408e可以被调度和执行过程1410调度为在定时t0-t4之间的各个时隙期间且在各个计算节点1412a-1412c处操作。小功能1408a可以被调度为在时间t0-t1之间在计算节点1412a上执行。由于其他小功能1408b-1408e要求来自小功能1408a的数据，因此没有一个其他小功能1408可以在时间t0-t1期间执行。

在小功能1408a完成执行之后，小功能1408b、1408c两者可以在时间t1–t2之间在计算节点1412a、1412b处执行。如依赖图1414中所例示的，小功能1408b、1408c可以并发地执行，因为小功能1408b、1408c两者仅需要来自小功能1408a的信息而不需要来自小功能1408e、1408e的信息。因而，在调度图1416中，小功能1408b、1408c在不同的计算节点1412a、1412b处并发地执行。在一些实施例中，如果计算节点1412a-1412c中的一个节点具有支持小功能1408b、1408c两者的足够资源，则小功能1408b、1408c两者可以被调度为在计算节点1412a-1412c中的该节点上执行。

在小功能1408b、1408c完成执行之后，小功能1408d可以在时间t2-t3期间在计算节点1412c上执行。小功能1408d的执行可以通过在计算节点1412c上找到的硬件加速器和/或fpga来增强。因而，调度和执行过程1410可进一步考虑资源(诸如硬件资源)是否可以增强小功能1408a-1408e中的一者的执行，并且相应地调度小功能1408a-1408e中的一者。此外，如依赖图1414中所例示的，小功能1408d可以需要来自小功能1408b、1408c的数据但不需要来自小功能1408e的数据来执行，并且因此被调度在小功能1408b、1408c之后来完成执行。

在小功能1408d完成执行之后，小功能1408e可以在时间t3-t4期间在计算节点1412c上执行。可以通过使小功能1408e在计算节点1412c上执行来增强资源效率。即，由于小功能1408e可能需要来自小功能1408d的数据，因此小功能1408e可以被调度为在与小功能1408d相同的节点上执行以最小化计算节点1412a-1412c之间的数据传递，并且增强存储器和高速缓存使用。因而，调度和执行过程1410可通过使数据传递最小化并且通过对小功能1408a-1408e的增强调度来增强高速缓存使用来进一步增强资源使用。

在一些实施例中，小功能1408a-1408e中的一者或多者可以在小功能1408a-1408e所需的资源变为可用时的稍后时间从重建状态执行。例如，假定小功能1408d要求硬件加速器以用于执行。小功能1408d可以被调度为响应于硬件加速器可用的标识来执行。小功能1408d的执行可以在小功能1408b、1408c完成执行之后的一段时间进行。即，小功能1408d不会在小功能1408b、1408c一完成执行就被自动触发开始执行。相反，小功能1408d可以被调度为在除了小功能1408b、1408c完成执行之外硬件加速器还变得可用时执行。

将功能1404分成小功能1408a-1408e可以降低功能1404的失败可能。例如，在一些实施例中，功能1404的操作中的一些操作可能要求特定硬件，诸如上文提及的小功能1408d。如果功能1404必须等待该硬件，则可能发生超时故障，其中功能1404在预定时间限制之前无法完成并且因此被放弃。

通过将功能1404分成一系列个体小功能1408a-1408e，此类超时故障可以被更好地避免，因为小功能1408a-1408e可以被分立地调度为仅在资源可用时操作。简言之，功能1404可以通过等待直到资源可用才发起小功能1408a-1408e而在小功能1408a-1408e之间被“暂停”。如所提及的，小功能1408e可以被调度为在硬件加速器变为可用时执行，而非开始执行且接着等待硬件加速器变为可用。

此外，分解过程1406以及调度和执行过程1410可通过在小功能1408a-1408e级别粒度捕获和释放资源来提供用于增强整体执行的机会，小功能1408a-1408e级别粒度比功能1404的粒度更精细。此外，可能将可以在专用硬件加速器上被加速的小功能(诸如小功能1408d)与更好地容适常规或基于cpu的软件执行的那些小功能(例如小功能1408a-1408c和1408e)进行混合。

此外，各实施例允许功能1404的简单流执行，其中功能1404被分解成连同排序的更小的小功能1408a-1408e，如依赖图1414中所例示的。调度和执行过程1414中实现的调度方案可以监视可用资源/需要那些资源的其他争用方的执行或优先级，以实现伺机调度同时维持小功能顺序。此外，开发人员可以不知悉增强的功能执行序列1400。这可以简化开发人员任务，因为开发人员不必标识子功能，因为进程是在csp侧不透明地执行的。

如上所述，小功能1408a-1408e可以根据依赖图1414所描述的排序依赖性被预设给执行平台。可以提供用于确保依赖图1414中的正确排序依赖性的架构支持，包括针对可以作为并发活动在地址空间边界内或跨地址空间边界被调度的小功能1408a-1408e的对使用扩充用户级中断(uli)、硬件队列管理器、远程原子(rao)等技术的高效逻辑屏障和事件协调的支持。小功能1408a-1408e还可以被分解为称为“迷你小功能”的更小的单元，它们与如上所述类似地执行。

增强的功能执行序列1400可以由一个或多个硬件队列管理器来协调。多个硬件队列管理器可以调度小功能1408a-1408e并使其排队。硬件队列管理器可以在不同节点上，但是可以按照依赖图1414的执行顺序来维持小功能1408a-1408e的队列并相应地调度。

增强的功能执行队列1400可以进一步由如上所提及的图13a的服务器1302来实现，但是也可以或结合服务器1302被实现在图4的增强的faas系统400(诸如编排器404)和/或一个或多个模块中作为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读的存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在增强的功能执行序列1400中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

作为示例，假定功能包括分析短发言文件。短发言文件的分析可以被分解为各个小功能(例如，组分操作)，包括将发言文件转换(转录)成文本，识别和分离不同参与者说出的单词和/或句子，以及按照说话者的身份来归类转录。通过如上文参照增强的功能执行序列1400所描述地将功能分解，获得功能的部分执行，以使得一些小功能通过特定量的资源在可用的时间量内完成。因而，将功能分解为各个小功能可以增强执行，降低资源使用并且减少等待时间。

图14c示出了在csp环境中调度具有多个操作的功能的方法1450，并且可以由图13a的服务器1302来执行，但是也可以或结合服务器1302被实现在图4的增强的faas系统400(诸如编排器404)和/或一个或多个模块中作为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读的存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法1450中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框1452可以确定功能的各操作(例如各个小功能)。所例示的处理框1453基于所标识的操作将功能分成各个小功能。例如，每一小功能可包括单个操作。在其他实施例中，在操作彼此有关(例如，利用类似的数据或者需要来自彼此的数据)的情况下，每一小功能可包括若干操作。所例示的处理框1454可以生成静态互相依赖图以确定各个小功能的顺序。例如且如上所提及的，顺序可包括确定各个小功能(例如各个操作)能够并发地还是串行地执行。所例示的处理框1456可以基于所确定的顺序来单独地调度各个小功能。例如，第一小功能(例如操作)可以在其他小功能(例如各操作)之前被调度，如果其他小功能依赖于来自第一小功能的数据。所例示的处理框1456可以进一步调度各个小功能中的第一小功能在第一计算节点处执行，各个小功能中的第二小功能在与第一计算节点不同的第二计算节点处执行。因而，可以促成并发调度，或者使用不同硬件(例如专用的和/或非专用的)来减少第一功能和第二功能的等待时间。

所例示的处理框1456还可在第一时间调度各个小功能中的第一小功能并且在与第一时间不同的第二时间调度各个小功能中的第二小功能。因而，第一小功能和第二小功能的串行执行可以被实现。此外，所例示的处理框1456可以调度第二小功能以响应于资源分配(例如，专用硬件加速器和/或fpga)可用的标识以及第一小功能完成的标识两者来开始执行。在此类实施例中，方法1450可进一步包括有意地延迟第二小功能的执行，直到资源分配可用。此外，第二小功能可以要求来自第一小功能的输出。

方法1450可增强csp环境的效率和操作。例如，方法1450可以减少等待时间，增强资源利用，并且增强功能的完成率。

附加注解与示例

示例1400包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：确定功能的各操作，确定各操作的顺序，基于所确定的顺序单独地调度各操作，调度各操作中的第一操作在第一计算节点处执行以及各操作中的第二操作在第二计算节点处执行，在第一时间调度第一操作，在与第一时间不同的第二时间调度第二操作，调度第二操作以响应于资源分配可用的标识以及第一操作完成的标识两者来开始执行，并且延迟第二操作的执行直到资源分配可用，其中第二操作要接收来自第一操作的输出。

示例1401包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：确定功能的各操作，确定各操作的顺序，基于所确定的顺序单独地调度各操作。

示例1402包括示例1401的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：调度各操作中的第一操作在第一计算节点处执行以及各操作中的第二操作在第二计算节点处执行。

示例1403包括示例1401的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在第一时间调度各操作中的第一操作，以及在与第一时间不同的第二时间调度各操作中的第二操作。

示例1404包括示例1403的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：调度第二操作以响应于资源分配可用的标识以及第一操作完成的标识两者来开始执行。

示例1405包括示例1404的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：延迟第二操作的执行直到资源分配可用。

示例1406包括示例1403的至少一种计算机可读介质，其中第二操作要接收来自第一操作的输出。

示例1407包括示例1400的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：基于用户输入来确定各操作。

用于faas的增强的存储器分配

图15a例示了根据一些实施例的性能和存储器存储增强的计算架构1500。此类示例可以由图13a的服务器1302(例如第一到第三计算节点1304a-1304c中的一者或多者)和/或图4的增强的faas系统400(诸如编排器404)来实现。

性能和存储器存储增强的计算架构包括容器1502和功能1504。功能1504可以结合容器1502来操作。例如，功能1504可以被加载到容器1502内。在一些实施例中，功能1504可以被下载并实例化到容器1504内。平台操作系统1506可以主存容器1502和功能1504，并且结合存储器1510来操作以存储用于容器1502和功能1504的数据。

如所例示的，平台操作系统1506可包括专用存储器容器列表1524和专用功能存储器列表1526。专用容器存储器列表1524和专用功能存储器列表1526可以是标识存储器1510中专用于功能1504和/或容器1502的地址范围的数据结构、数组或查找表。例如，专用容器存储器列表1524标识基础容器存储器空间1520a-1520c。专用功能存储器列表1526标识功能存储器空间1522a、1522b。如所例示的，存储器1510还可包括未被分配的存储器空间1530。

在平台操作系统1506接收到存储器分配请求时，平台操作系统1506可以确定功能1504还是容器1502是该存储器分配请求的源头。如果容器1502是该存储器分配请求的源头，则可以基于专用容器存储器列表1524来提供存储器分配。例如，存储器分配可以是由专用容器存储器列表1524所标识的存储器范围的分配。因此，容器1502可以基于从平台操作系统1506接收到的存储器分配将数据存储和写入基础容器存储器空间1520a-1520c。因而，容器1502可以通过基础容器存储器空间1520a-1520c被预设标准的、受信的存储器部分。

作为对比，如果功能1504是该存储器分配请求的源头，则可以基于专用功能存储器列表1526来提供存储器分配。例如，存储器分配可以是由专用功能存储器列表1526所标识的存储器范围的分配。因此，功能1504可以将数据存储和写入功能存储器空间1522a、1522b。

由此，容器1520的特定于容器的数据以及仅由功能1504使用的特定于功能的数据可以被存储在不同的基础容器存储器空间1520a-1520c和功能存储器空间1522a、1522b中。特定于容器的数据可以被许多不同功能重用，并且在功能1504的执行期间无法被功能1504更改。

一旦功能1504终止，例如通过完成执行或发生错误，存储在功能存储器空间1522a、1522b中的特定于功能的数据就可以被擦除。在功能1504完成执行时，存储在基础容器存储器空间1520a-1520c中的特定于容器的数据可以不被擦除。由此，即便在功能1504终止且不再执行时，容器1502保留在半温暖状态中以准备好接收另一要执行的功能。因而，通过限制在功能1504终止时被擦除的数据可以避免整个容器1502的拆除。通过使功能1504仅将数据存储到功能存储器空间1522a、1522b中，仅受到功能1504影响的改变可以从容器1502的状态中被移除，藉此使容器1502保留在具有存储在基础容器存储器空间1520a-1520c中的受信代码的半温暖状态中。由此，通过在特定于功能的数据以及特定于容器的数据之间划分数据并且相应地存储，可以促成与功能1504相关联的数据的删除以增强安全性并且减少高等待时间的冷容器启动。

详细来说，对于各种容器类型，用于终止和重启容器1502的开销可能过高并且增加等待时间。例如，如果容器1502用于神经网络(例如，卷积神经网络或深度神经网络)，则容器1502终止并且接着再次旋转加速可能过于昂贵。这可能是因为神经网络包括要操作的极大数据负载(例如，神经权重和/或恒定值)。此类数据负载可以是容器1502的一部分，因为数据负载可以被不同功能重用并且无法被功能更改。因而，如果功能1504出错，则容器1502可能被迫使终止并且被再次旋转加速，这增加了等待时间并且降低了效率。

计算架构1500可以增强功能1504的终止过程。例如，如果功能1504出错，则平台操作系统1506可以限制被终止的数据的范围。即，仅存储在功能存储器空间1522a、1522b中的数据可以被擦除或解除分配。因此，仅受到功能1504影响的改变从容器1502的状态中被移除，并且避免了整个容器1502的拆除。如所例示的，平台操作系统1506向容器1502提供了维持两个不同资源集的能力，两个不同资源集包括为要在容器1502中运行的功能1504分配和使用的功能存储器空间1522a、1522b以及为容器1502本身分配和使用的基础容器存储器空间1520a-1520c。

此外，由于功能1504的敏感数据在功能1504终止之后被擦除，因此增强了安全性。例如，特定于功能1504的敏感数据可以从功能存储器空间1522a、1522b中被擦除。

平台操作系统1506可以结合虚拟机监视器(未例示)以及容器1502或功能1504中的一者或多者所使用的库来操作。平台操作系统1506、虚拟机监视器以及库中的一者或多者可以实现确定存储器分配调用(例如，malloc、calloc等)是否源自作为容器1502的一部分的被列为白名单的代码范围或容器1502的已知且经验证的执行主体的机制。如果存储器分配调用源自被列为白名单的代码范围或者容器1502的已知且经验证的主体，则向该存储器分配调用提供来自基础容器存储器空间1520a-1520c的存储器范围。否则，默认地，存储器分配调用被假定为源自功能1504的代码，并且接着被给予来自功能存储器空间1522a、1522b的存储器范围。专用功能存储器范围可以被认为是“临时”范围。

如果例如作为分割违背的结果需要执行清除或拆除循环，代替拆除基础容器存储器空间1520a-1520c，仅仅拆除功能1502的功能存储器空间1522a、1522b。例如，专用容器存储器列表1524可包括被容器1502利用的所有被分配的存储器空间的列表。同样地，专用功能存储器列表1526可包括被功能1504利用的所有被分配的存储器空间的列表。在清除期间，分配给功能1504的存储器空间可以被拆除和擦除，同时使分配给容器1502的存储器空间保持不变。

此外，任何类型的存储器分配调用，例如，符合便携式操作系统接口的unix(posix)系统调用(例如，mmap()调用)或动态存储器分配调用(例如，malloc、calloc等)可以如上文所描述地那样被标识和恰适地引导。例如，如果从功能1504接收到mmap()调用，则可以基于专用功能存储器列表1526来提供被配备用于映射的虚拟存储器范围。因而，专用功能存储器列表1526可包括虚拟存储器范围的标识。因此，仅那些虚拟存储器范围和任何相关联的物理存储器范围可能需要被回收。

此外，文件描述符可以被类似地处理。例如，对于“open()”命令，平台操作系统1506可以在专用容器存储器列表1524和专用功能存储器列表1526中维护两个不同的文件描述符群。专用容器存储器列表1524和相关联的基础容器存储器空间1520a-1520c中的文件描述符在功能1504的异常条件或终止之际不必被终止或关闭(但可能需要被重新发起、重建或重新打开或重新初始化)。专用功能存储器列表1526和相关联的功能存储器空间1522a、1522b中的文件描述符在功能1504的异常条件或终止之际可以总是被关闭。

在功能1504例如由于非法指令或分割违背引起的陷入而终止时，容器1502可以执行功能1504的清除而容器1502本身不会被迫退出。如上所提及的，平台操作系统1506、软件库和虚拟机监视器中的一者或多者可以促成功能1504的拆除。

在一些实施例中，平台操作系统1506和/或容器1502除了功能1504之外还可以拆除容器1502。即，在容器1502被标识为引起错误时，基础容器存储器空间1520a-1520c可以被擦除。例如，如果作为从容器1502的白名单主体内部执行的代码的结果而发生终止条件(诸如非法指令错误)，则除了功能1504之外该进程或容器1502也应当被拆除。在一些实施例中，在容器1502保持未被功能使用达预定时间量的情况下，容器1502可以被拆除。

在一些实施例中，在功能1504在完成之前(例如，因错误)终止时，可以在容器1502中定义特殊进入点。进入点是在功能1504被拆除且功能存储器空间1522a、1522b被解除分配之后执行被指向的位置。重新进入点可以是在温暖启动期间容器1502执行功能启动时的位置。例如，重新进入点可以是容器1502已经完全初始化且准备好开始功能1504的处理的启动点。定向到该重新进入点可以等效于对该启动点的“长跳转调用”。

可以对各个命令或库接口作出各种调整以促成恰适的分配和解除分配。例如，通常需要“回溯”命令来确定各个分配的源头，但是可以通过具有用于各个分配和“开放调用”的两个不同的进入点来避免该“回溯”命令。例如，一个进入点仅被链接到白名单代码，而另一进入点则是功能1504的代码的默认。可以针对其他类型的预设调用(诸如“mmap()”(其需要提供虚拟范围)、“open()”(其分配文件描述符、socket()等))完成类似的命令分叉。在每一种情形中，可以假定白名单代码被链接到按正常方式进行分配的代码，而非白名单代码经过经由专用功能存储器列表1526将资源隔绝在功能存储器空间1522a、1522b中，或者跟踪已打开的文件描述符、套接字等作为与功能1504相关联的、在发生错误时需要被自动释放/自动关闭的数据的路径。

因而，增强的计算架构1500可包括若干增强，包括对容器的有限拆除、对冷容器的有限初始化，藉此降低成本。此外，增强的计算架构1500可以增强资源利用效率，因为利用较少的带宽和功率来拆除和重建容器。此外，增强的计算架构1500具有由于容器从半温暖状态的更快速的启动引起的更少的等待时间以及来自功能终止和错误的更少开销。还可以通过从功能存储器空间1522a、1522b中移除特定于功能的数据来增强安全性。

图15b示出了用于功能和容器的存储器分配的方法1550，并且可以由图13a的服务器1302执行，但也可以或结合服务器1302被实现在图4的增强的faas系统400和/或一个或多个模块中作为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos、或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法1550中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框1552可以将一个或多个容器存储器空间专用于容器。所例示的处理框1554可以将一个或多个功能存储器空间专用于与该容器相关联的功能。所例示的处理框1556可以接收存储器分配请求。所例示的处理框1558可以确定存储器分配请求是源自容器还是功能。所例示的处理框1560可以基于存储器分配请求是源自容器还是功能来提供来自一个或多个容器存储器空间或一个或多个功能存储器空间的存储器分配。例如，在存储器分配请求源自容器时，存储器分配可以来自一个或多个容器存储器空间。作为对比，在存储器分配请求源自功能时，存储器分配可以从一个或多个功能存储器空间提供。

此外，仅用于容器运行的数据可以被存储在一个或多个容器存储器空间中。此外，特定于功能的数据仅被存储在一个或多个功能存储器空间中。

所例示的处理框1562可以响应于功能已经终止的标识来解除分配来自一个或多个功能存储器空间的存储器但不解除分配来自一个或多个容器存储器空间的存储器。尽管未例示，但是该方法可进一步包括将另一功能加载到容器内以供执行。因而，方法1550可包括若干增强，包括对容器的有限拆除以及对冷容器的有限初始化，藉此降低成本。此外，方法1550可以增强资源利用效率，因为利用较少的带宽和功率来拆除和重建容器。此外，方法1550可由于容器从半温暖状态的更快速的启动而具有更少的等待时间，并且具有来自功能终止和错误的更少开销。

附加注解与示例

示例1500包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：将一个或多个容器存储器空间专用于容器，以及将一个或多个功能存储器空间专用于与容器相关联的功能，接收存储器分配请求，确定该存储器分配请求源自容器还是功能，在该存储器分配请求源自容器时提供来自一个或多个容器存储器空间的存储器分配，在该存储器分配请求源自功能时提供来自一个或多个功能存储器空间的存储器分配，以及响应于功能终止的标识来解除分配来自一个或多个功能存储器空间的存储器但不解除分配来自一个或多个容器存储器空间的存储器，其中仅供容器操作的数据被存储在一个或多个容器存储器空间中，而特定于功能的数据仅被存储在一个或多个功能存储器空间中，其中一个或多个容器存储器空间用于存储文件描述符或套接字描述符中的一者或多者。

示例1501包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：将一个或多个容器存储器空间专用于容器，以及将一个或多个功能存储器空间专用于与容器相关联的功能。

示例1502包括示例1501的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：接收存储器分配请求，确定该存储器分配请求源自容器还是功能，以及基于该存储器分配请求源自容器还是功能来提供来自一个或多个容器存储器空间或一个或多个功能存储器空间的存储器分配。

示例1503包括示例1502的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在该存储器分配请求源自容器时提供来自一个或多个容器存储器空间的存储器分配。

示例1504包括示例1502的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在该存储器分配请求源自功能时提供来自一个或多个功能存储器空间的存储器分配。

示例1505包括示例1501的至少一种计算机可读介质，其中仅供容器操作的数据被存储在一个或多个容器存储器空间中，而特定于功能的数据仅被存储在一个或多个功能存储器空间中。

示例1506包括示例1501的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：响应于功能终止的标识，解除分配来自一个或多个功能存储器空间的存储器分配但不解除分配来自一个或多个容器存储器空间的存储器。

示例1507包括示例1506的至少一种计算机可读介质，其中一个或多个容器存储器空间用于存储文件描述符或套接字描述符中的一者或多者。

功能到温暖容器和冷容器的分发

各个功能可以在温暖容器和冷容器之间具有随机分布。如本文已经描述的，用于初始化冷容器的等待时间可能不是微不足道的。由此，分发到冷容器的功能可具有较高的等待时间，因为冷容器必须通过例如被预设来初始化并且接着功能必须执行。作为对比，分发到温暖容器的功能可具有较低的等待时间，因为可以避免冷容器初始化。

冷容器初始化等待时间可以由初始化的许多阶段和各个因素引起。一组因素可以是分配和配置os级资源，诸如用于资源id(例如，进程id和文件描述符)和控制群的名称空间，以限制分配给容器的各个资源(例如，cpu和存储器)的量。另一组因素可以是初始化容器的内容，诸如用于托管语言(诸如java)的语言运行时。启动功能本身也引起附加开销。温暖容器可以提前执行这些阶段中的某一数目的阶段，以减少调用被主存在温暖容器内的功能的等待时间。

常规调度在分发功能时可能不考虑冷容器初始化所要求的时间，也不考虑如何使冷容器初始化最小化。此外，一些调度可能在温暖容器和冷容器之间具有低效的功能分布，从而导致较高的资源使用和较高的等待时间执行。

现在转向图16a，示出了示例1600，其中功能请求1604被faas系统(例如图4的faas系统400)的调用器和批量均衡器1606调度。调用器和批量均衡器1606可以实现批量实现以减少等待时间并增强资源利用。例如，一些实施例可以标识各自都请求可批量处理的功能的执行的前n个可批量处理的功能请求1608a-1608n。前n个可批量处理的功能请求1608a-1608n可以在一起被批量处理并被先行调度，以使得可批量处理的功能在同一容器1614a中而非在不同容器中执行。因此可以通过可批量处理的功能的批量执行来减少冷容器初始化以减少等待时间并利用较少的容器。

此外，调用器和批量均衡器1606可以标识与功能请求1604相关联的特定功能的等待时间约束，并且分发功能请求1604以满足该等待时间约束。等待时间约束可以与功能应当完成执行的所请求的时间相对应。例如，在等待时间约束准许时，较短等待时间的功能可以被分组在一起并被排序，以使得该组中的每一功能的全部等待时间约束被满足。以上分析尤其可以增强其中功能的程序代码在长度上变化很大的特定情景。一种此类情景可以是在具有松等待时间约束(例如长等待时间约束)的长功能和具有紧等待时间约束(例如短等待时间约束)的短功能被调度在一起的情景。首先调度短功能使得长功能和短功能两者的等待时间约束均能够被满足。作为对比，首先调度长功能导致短功能的等待时间要求无法被满足。

在一些实施例中，“最早期限优先”的调度策略被用于生成可行调度。因而，具有最短等待时间约束的功能被调度在具有较长等待时间约束的功能之前。在一些实施例中，替换调度方案(诸如“最短作业优先”)和实现(例如，轮回(roundrobin))可以被使用。因此，例如，最短功能在较长功能之前被执行，并且可以按照轮回方式来执行。

在一些实施例中，“最早期限优先”和“最短作业优先”的混合模型可以被采用。例如，“最短作业优先”策略可以安排最短功能在较长功能之前执行。系统接着可以分析全部功能(例如，预测完成各个功能所需的定时并将定时与相关联的等待时间约束作比较)以预测是否全部的等待时间约束将被满足。如果是，则系统可以根据所确定的安排来调度各个功能。

如果一些功能的等待时间约束将不被满足，则系统可以基于“最早期限优先”策略来修改安排，以使得其等待时间约束将不被满足的那些功能将在其等待时间约束被满足的其他功能之前执行。作为一个示例，假设f1、f2、f3和f4被“最短作业优先”策略调度为按照该顺序执行。如果标识f2和f3将不满足等待时间约束，则系统可以将f2、f3移动到f1、f4之前执行。为了确定是f2还是f3先执行，系统可以执行“最早期限优先”策略，并且确定f3在f2和f3之间具有最早期限并且应当被调度在f2之前。因而，最终顺序将类似于：f3、f2、f1和f4。

在一些实施例中，诸如从各个遥测源(例如，对先前的功能执行计时的计时器)收集的历史信息可以被用于估计每一功能的执行时间，这可以有助于通知功能的将来调用的调度。对于更多细节，参见图24a和图41a的讨论。一些实施例还可确定处理可批量处理的功能时冷容器初始化是否是必要的，并且如果是，则在标识等待时间约束是否将被满足时考虑用于冷容器初始化的等待时间。

因而，一些实施例可以限制冷容器初始化，同时具有功能的更有效分发以减少资源使用。例如，使若干功能在同一容器内执行而非初始化若干新的冷容器来执行功能可能是更资源高效的。显而易见的是，除了第一功能之外，在串行执行模型中批量处理的功能需要等待在前的批量处理功能完成，相对于采用其中专用容器中的功能不必等待任何其他功能完成的无限并行化模型，这可能增加等待时间。尽管如此，一旦考虑并行化的限制并将初始化时间的降低纳入考虑，批量处理的功能的总等待时间以及甚至不是第一功能的功能的等待时间实际上可以更低。因而，一些实施例可能由于增强的温暖容器使用而具有更低的等待时间，甚至在功能在一起被批量处理的情况下也是如此。多个批量处理的功能在单个容器中的并行执行可进一步减少等待时间。

此外，如上所提及的，资源管理可以被增强。例如，在某一量的空闲时间之后，温暖容器可以被拆除。空闲时间可以是在此期间温暖容器不处理任何功能的时间。通过如本文所描述的通过批量处理实现使温暖容器被更经常地利用，各实施例可以展现频率较低的冷容器初始化和频率较低的温暖容器拆除，因为温暖容器被更频繁地使用。此外，一些实施例可具有消耗资源的相同容器的较少实例。例如，代替每一功能具有一个容器，一个容器可服务于若干功能。因而，各实施例增强效率并且利用更少的资源来降低成本。因此，即便前n个可批量处理的功能请求1608a-1608n按照突然且不频繁的猝发而发生，也可以避免冷容器损失，并且允许增强的faas系统对容器的构建和拆除的更多控制。

此外，负载均衡成本可以被降低。例如，由编排器单独地调度每一功能可以要求更多的计算资源，与一起调度一批功能相反。此外，消息收发开销可以被降低，但是由于可能不是针对每一功能请求发送单独消息，相反可以传送包括全部前n个批量处理的功能请求1608a-1608n的批量处理的功能请求消息。

如示例1600中所例示的，功能请求1604被faas系统(例如图4的faas系统400)的调用器和批量均衡器1606调度。调用器和批量均衡器1606可以是编排器404的一部分，或者结合编排器404来操作。

如图16a中所例示的，事件处置api代理1602可以将事件调用路由到与功能请求1604相关联的功能。在1600的示例中，api代理1602可以经由例如api来生成功能请求1604。功能请求1604可以被提供给调用器和批量均衡器1606。功能请求1606可以各自是执行相应功能的请求。

调用器和批量均衡器1606可以分析功能请求1604以标识功能请求1604是否可以被批量处理。详细来说，调用器和批量均衡器1606可以确定功能请求1604的功能是否可以在容器1614a-1614c中的同一容器中执行。各请求可以被允许构建，除非存在强等待时间约束，并且接着它们可以作为批次根据该批次中包含多少工作负载而被发送到可用的温暖容器或新的冷容器。因而，在此类可任选的批量处理下，在各动作被触发时，各动作的负载均衡、调用和执行全部以解耦合的方式(例如，两阶段的方式)来执行。可以在容器1614a-1614c中的同一容器中执行的各功能可以在一起被批量处理。在一些实施例中，调用器和批量均衡器1606可以确定相同的功能可以在一起被批量处理。此外，调用器和批量均衡器1606可以在不相同的功能可以在容器1614a-1614c中的同一容器中执行的情况下确定不相同的功能可以在一起被批量处理。

调用器和批量均衡器1606可以标识来自功能请求1604的不可批量处理的功能请求1610、1612。不可批量处理的功能请求1610、1612可以请求无法与其他功能被分组在一起且因此被认为是不可批量处理的不可批量处理的功能。不可批量处理的功能请求1610、1612可以被单独地发送到容器1614b、1614c。即，不可批量处理的功能可以在分开的容器1614b、1614c中执行。容器1614b、1614c可以是温暖的或冷的，其中向不可批量处理的功能请求1614b、1614c中具有最强等待时间约束的不可批量处理的功能请求赋予优先级。

如所例示的，调用器和批量均衡器1606可以标识来自功能请求1604的前n个可批量处理的功能请求1608a-1608n。如所描述的，前n个可批量处理的功能请求1608a-1608n中的每一者可以调用被配置成在同一容器内执行的功能(其可以被称为“可批量处理的功能”)。因此，前n个可批量处理的功能请求1608a-1608n可以被发送到容器1614a。可批量处理的功能可以在容器1614a内执行。前n个可批量处理的功能请求1608a-1608n可包括大于1的任何数目的功能请求。

在一些实施例中，与前n个可批量处理的功能请求1608a-1608n相关联的可批量处理的功能可以同时在容器1614a中执行，如果容器1614a具有支持此类同时执行的足够资源的话。例如，调用器和批量均衡器1606可以确定可批量处理的功能中的每一者的资源要求，并且确定容器1614a是否具有对足够的资源(例如cpu和存储器)的访问权以同时满足全部的资源要求。如果是，则同时执行可以被调度。如果否，则同时执行无法被支持，并且可批量处理的功能可以被串行地(一个接着一个地)执行。

在一些实施例中，调用器和批量均衡器1606可以确定可批量处理的功能的安全协议。如果安全协议指示特定可批量处理的功能具有特定安全要求(例如高安全性)，则该特定可批量处理的功能可以被调度为用于容器1614a中的非同时执行，并且执行容器1614a的有限拆除，其中在维持容器1614a的数据的同时仅该特定可批量处理的功能的数据被移除，如参考图15a-15b和以上相关联的描述所描述的。

在一些实施例中，可批量处理的功能中的一些可以被同时执行，而可批量处理的功能中的另一些可以被串行地执行。在一些实施例中，容器1614a可以执行第一组可批量处理的功能，例如，可以由容器1614a的资源支持的最大数目的可批量处理的功能。在第一组完成执行之后，第二组可批量处理的功能可以开始执行，例如，可以由容器1614a的资源支持的最大数目的可批量处理的功能。因而，调用器和批量均衡器1606可以基于安全协议和相对于功能的资源要求的容器1614a的资源可用性来调度可批量处理的功能的混合式串行和并行执行。

在一些实施例中，容器1614a可包括分区的工作空间以将并行执行的可批量处理的功能分隔开。每一功能可以在不同分区中执行。全部的分区可以访问可以被任何可批量处理的功能利用的共用数据。分区可具有分隔开的存储器空间以保持特定于功能的数据。因此，每一分区可以将由功能生成的数据保存在分隔开的存储器空间中，同时访问功能所使用的共用数据。在功能在一个分区中完成执行之后，来自对应的分隔开的存储器空间的数据可以被保存到另一数据存储(如果需要的话)，并且该分隔开的存储器空间被擦除以使该分区准备用于另一功能。然而，在执行期间共用数据可能无法被功能更改，并且共用数据可以被在容器1614a中执行的每一功能重用。

在一些实施例中，调用器和批量均衡器1606可以累积功能请求1604。例如，功能请求1604可以各自在不同时间被发送到调用器和批量均衡器1606。调用器和批量均衡器1606可允许功能请求1604累积达一时间段。即，调用器和批量均衡器1606可以不在接收到功能请求1604时立即调度功能请求1604.相反，调用器和批量均衡器1606可以在调度功能请求1604之前进行等待。这么做可以允许调用器和批量均衡器1606接收诸多潜在的可批量处理的功能请求1604，并且接着基于功能请求1604是否可以在一起被批量处理来调度功能请求1604。

在一些实施例中，调用器和批量均衡器1606可以确定功能请求1604中的每一者的等待时间约束，并且相应地调度相关联的功能。例如，不可批量处理的功能请求1610可具有强等待时间约束。即，不可批量处理的功能请求1610可能由于相关联的等待时间约束而需要被调度为立即执行对应的功能。等待时间约束可以是数值和/或绝对时间。等待时间约束可以指示不可批量处理的功能请求1610的相关联的功能可能需要在短时间帧内完成。因而，不可批量处理的功能请求1610可以被调度为在可以是温暖容器的容器1614b内执行。

在一些实施例中，如果功能请求1604中的一个功能请求的等待时间约束满足不可批量处理的阈值，则该功能请求可以被自动分类为不可批量处理以确保及时的执行。例如，如果等待时间约束指示该功能必须在预定时间量之内被完成，则对应的功能请求可以被立即调度，而不标识与该对应功能请求批量处理的其他可批量处理的功能。

在一些实施例中，调用器和批量均衡器1606可以进一步确定前n个可批量处理的功能请求1608a-1608n中的每一者的等待时间约束。调用器和批量均衡器1606可以基于目前已经接收到的前n个可批量处理的功能请求1608a-1608n的最强等待时间约束来等待前n个可批量处理的功能请求1608a-1608n的调度。

例如，调用器和批量均衡器1606可以根据等待时间约束确定前n个可批量处理的功能请求1608a-1608n的每一相应功能要完成执行的时间帧。该时间帧可以与在此期间相应可批量处理的功能应当完成执行的优选时间窗口相对应。各个时间帧中的最短时间帧可以被确定。调用器和批量均衡器1606可以将前n个可批量处理的功能请求1608a-1608n发送到容器1614a以满足该最短时间帧。例如，调用器和批量均衡器1606可以在第一时间将前n个可批量处理的功能请求1608a-1608n发送到容器1614a以确保具有该最短时间帧的功能在该最短时间帧内完成。然而，调用器和批量均衡器1606可以继续接收和累积功能请求1604，直到达到第一时间。由此，调用器和批量均衡器1606可以在将前n个可批量处理的功能请求1608a-1608n发送到容器1614a之前等待一时间段并且遵守等待时间约束。

在一些实施例中，调用器和批量均衡器1606可以确定为了遵守等待时间约束要开始特定功能的执行的定时。调用器和批量均衡器1606可以确定完成该特定功能的执行所需的总预计等待时间。总预计等待时间可包括初始化冷容器所需的时间、调用器和批量均衡器1606已经在累积功能请求1604方面花费的时间、被调度在该特定功能之前在容器中执行的功能的等待时间、通信等待时间和/或该特定功能在容器中完成执行的等待时间。以下等式1600可以被用于基于总预计等待时间与可接受等待时间的比较来确定该特定功能的等待时间约束是否会被满足：

l等待+lccl+lf+lc≤l可接受

等式1600

在以上等式600中，l可接受是调用器和批量均衡器1606已经累积该特定功能的特定功能请求的时间段。例如，l可接受可以是当前时间与接收到该特定功能请求的时间之差。lccl是初始化冷容器所需的时间。如果温暖容器被标识为正可用，则lccl可以被设置为0。lf是被调度在该特定功能之前执行的每一功能的预计执行等待时间以及该特定功能要完成执行的预计等待时间。因而，lf可以是总功能执行等待时间估计。lc是将前n个可批量处理的功能请求1608a-1608n发送到容器1614a的通信等待时间。l可接受可以根据等待时间约束来确定，并且可以是该特定功能的总可接受等待时间。例如，l可接受可以是由服务提供商或客户端设置的阈值，并且可以是该功能被预期在此之内完成执行的总时间。如果该功能以等于或小于l可接受的等待时间完成执行，则该功能可以被认为被及时完成。如果以上为真或者如果l可接受大于或等于l等待、lccl、lc和lf的总和，则等待时间约束可以被认为被满足。在一些实施例中，调用器和批量均衡器1606可以仅在l可接受大于该总和达预定量的情况下才认为等待时间约束被满足。

基于以上等式1600，调用器和批量均衡器1606可以确定开始该特定功能的执行的起始定时。调用器和批量均衡器1606可进一步确定为满足该起始定时传送前n个可批量处理的功能请求1608a-1608n的传输时间。例如，调用器和批量均衡器1606可以确定静态值，诸如lccl和lc，并且通过控制前n个可批量处理的功能请求1608a-1608n被发送到容器1614a的定时(传输时间)以及容器1614a中可批量处理的功能执行的顺序来调整动态等待时间，诸如l等待和lf。

在一些实施例中，调用器和批量均衡器1606可以响应于正被累积的前n个可批量处理的功能请求1608a-1608n的特定数目将前n个可批量处理的功能请求1608a-1608n发送到容器1614a。例如，容器1614a可以能够支持受支持数目的功能的并发执行。由此，在前n个可批量处理的功能请求1608a-1608n的功能数目达到受支持的数目时，前n个可批量处理的功能请求1608a-1608n可以被发送到容器1614a以开始执行。在一些实施例中，各功能可以并发地在容器1614a内的独立软件线程上运行，并且因此各功能可以并行执行。在一些实施例中，功能可以以时间共享的模式在可用线程上执行。

因而，在以上示例中，前n个可批量处理的功能请求1608a-1608n可以在不同时间被调用器和批量均衡器1606接收和累积。调用器和批量均衡器1606可以将前n个可批量处理的功能请求1608a-1608n作为一个批次发送到可以是温暖的或冷的容器1614a。调用器和批量均衡器1606可以根据在该批次中可存在多少工作且为了满足相关联的等待时间约束来调度该批次。因而，在此类批量处理的方案之下，在各功能被触发时，各功能的负载均衡、调用和执行可以以解耦合的方式(两阶段的方式)来执行。

在一些实施例中，前n个可批量处理的功能请求1608a-1608n可以被调用器和批量均衡器1606根据等待时间约束分成两个或更多个组。例如，前n个可批量处理的功能请求1608a-1608n可以被划分，以使得第一组具有最强等待时间约束，第二组具有次最强等待时间约束，并且以此类推。

可以发生通过两个或更多个容器对两个或更多个组的并发执行以减少等待时间。在一些实施例中，如果不存在用于两个或更多个组的足够的温暖容器，则可以根据等待时间约束来指派温暖容器。例如，具有最强等待时间约束(用于执行的最短时间窗口)的组可以被发送到温暖容器，而具有较弱等待时间约束(用于执行的较长时间窗口)的组可以被发送到冷容器。例如，可以作出来自前n个可批量处理的功能请求1608a-1608n的等待时间约束的标识。前n个可批量处理的功能请求1608a-1608n可以根据等待时间约束被分组，以使得具有用于完成执行的最短时间窗口的功能在温暖容器中执行。作为对比，具有用于完成执行的较长时间窗口的功能可以被分组在一起以在冷容器中完成执行。

在一些实施例中，各个组可以被调度为一个接着一个在同一容器1614a中执行。具有最强等待时间约束的群可以被调度在具有较弱等待时间约束的群之前执行。

此外，在一些实施例中，调用器和批量均衡器1606可以作为从faas基础设施的前端到后端的粗粒度分派来操作以调度功能的批量处理。例如，在后端，前n个可批量处理的功能请求1608a-1608n可以被给予在其中相关联的功能按正常方式执行的容器1614a。作为对比，对faas的商业、高容量的使用可能基于个体功能请求调度方案而要求更多资源来执行负载均衡、容器指派和传输操作(全部的这些可以是单纯的开销)。

此外，本文描述的批量处理的调度方案可以自动地降低冷容器与温暖容器之比。详细来说，冷容器仅对于一个批次中的第一动作(例如功能)而言是冷的，但是对于该批次中的其余动作而言是热的。此外，较少的冷容器被构建以容适各个功能，从而降低了冷容器与温暖容器之比。如上所提及的，功能不可以被延迟超过基于等待时间约束的阈值历时，并且此时该功能所在的任何批次均被推送以供执行。

现在转到图16b，半导体封装装置1620的实施例可包括一个或多个衬底1624和耦合到一个或多个衬底1624的逻辑1622，其中逻辑1622至少部分地在一个或多个可配置逻辑和固定功能硬件逻辑中实现。耦合至一个或多个衬底1624的逻辑1622可以被配置成接收各自请求相应功能的执行的多个功能请求，以及从该多个功能请求中确定可批量执行的功能请求。在一些实施例中，逻辑1622可以被配置成将可批量处理的功能请求发送到同一容器。例如，逻辑1622可以被配置成确定该同一容器是温暖的，并且响应于确定该容器是温暖的，确定可批量处理的功能请求要被发送到该同一容器。在一些实施例中，耦合到一个或多个衬底1624的逻辑1622可以包括位于一个或多个衬底1624内的晶体管沟道区。

逻辑1622、以及装置1620的其他组件的实施例能以硬件、软件或其任何组合(至少包括部分硬件实现)来实现。例如，硬件实现可包括诸如例如pla、fpga、cpld之类的可配置逻辑、或使用诸如例如asic、cmos或ttl技术之类的电路技术的固定功能逻辑硬件、或者其任何组合。此外，这些组件的部分可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中将由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

装置1620可以实现方法1650、1670和1690(图16c、16d和16e)的一个或多个方面，或本文讨论的实施例中的任一个。在一些实施例中，所示装置1620可包括一个或多个衬底1624(例如，硅、蓝宝石、砷化镓)以及耦合到衬底1624的逻辑1622(例如，晶体管阵列和其他集成电路/ic组件)。逻辑1622可至少部分地被实现在可配置逻辑或固定功能逻辑硬件中。在一个实例中，逻辑1622可包括位于(例如，嵌入)(多个)衬底1624内的晶体管沟道区。因此，逻辑1622与(多个)1624之间的接口可以不是突变结。逻辑1622还可被认为包括在(多个)衬底1624的初始晶片上生长的外延层。

图16c示出了批量处理功能请求的方法1650，且可以由图13a的服务器1302执行，但也可以或结合服务器1302被实现在图4的增强的faas系统400和/或一个或多个模块中作为存储在诸如ram、rom、prom、固件、闪存等的机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法1650中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框1652可以接收各自请求相应功能的执行的多个功能请求。所例示的处理框1654可以确定来自该多个功能请求的可批量处理的功能请求。所例示的处理框1656可以将可批量处理的功能请求发送到同一容器。所例示的处理框1656可以进一步确定该同一容器是温暖的，并且基于该同一容器是温暖的来确定可批量处理的功能请求要被发送到该同一容器。

所例示的处理框1658可以确定来自该多个功能请求的不可批量处理的一个或多个不可批量处理的功能请求。所例示的处理框1660可以将一个或多个不可批量处理的功能请求中的每一者发送到不同的容器。

图16d示出了批量处理两个或更多个功能请求的方法1670，且可以由图13a的服务器1302执行，但也可以或结合服务器1302被实现在图4的增强的faas系统400和/或一个或多个模块中作为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

所例示的处理框1672可以接收第一可批量处理的功能请求。所例示的处理框1674可以确定第一可批量处理的功能请求要被批量处理。所例示的处理框1676可以等待直到接收到第二可批量处理的功能请求。即，第一可批量处理的功能请求可以不被立即发送到容器以供执行和/或不被立即调度。相反，方法1670可以等待接收其他功能请求以便在调度之前有效地将功能请求一起放置在一个批次中。所例示的处理框1678可以确定第一和第二可批量处理的功能请求可以在一起被批量处理。所例示的处理框1680可以确定第一和第二可批量处理的功能请求的一个或多个等待时间约束。如本文已经描述的，等待时间约束可以反映第一和第二可批量处理的功能请求所调用的功能应当完成执行的所请求的时间。所例示的处理框1682可以基于一个或多个等待时间约束来确定将第一和第二可批量处理的功能请求发送到同一容器的传输时间。详细来说，传输时间可以确保第一和第二可批量处理的功能请求遵守一个或多个等待时间约束或者在所请求的时间之前完成执行。所例示的处理框1684可以在传输时间将第一和第二可批量处理的功能请求发送到同一容器。

在一些实施例中，所例示的处理框1680、1682可以与所例示的处理框1674、1676、1678中的一者或多者同时或在其之前发生。例如，第一可批量处理的功能请求的等待时间约束可以与框1674同时地标识。此外，所例示的处理框1674可以基于第一可批量处理的功能请求的等待时间约束来确定第一可批量处理的功能请求是非紧急的且可以等待其他功能请求。此外，所例示的处理框1676可以等待其他功能达一时间段，该时间段遵守第一可批量处理的功能请求的等待时间约束。

图16e示出了调度功能请求以遵守等待时间约束的方法1690，且可以由图13a的服务器1302执行，但也可以或结合服务器1302被实现在图4的增强的faas系统400和/或一个或多个模块中作为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中看，或被实现为以上任何组合。

所例示的处理框1692接收功能请求。例如，编排器可以接收该功能请求并且调度该功能请求。所例示的处理框1694可以确定该功能请求的等待时间约束。如上所述，等待时间约束可以反映该功能请求所调用的功能的总可接受等待时间。等待时间约束可以是反映该功能的优选完成定时的数字测量(例如5ms)和/或绝对时间(例如2:48est)。在一些实施例中，等待时间约束可取决于另一功能请求。例如，该功能可以对来自另一功能的数据操作，并且因此等待时间约束可以反映该功能应当在该另一功能的完成的预定时间量内完成执行。在一些实施例中，等待时间约束可以反映该功能请求的功能要尽可能快地被执行而不等待批量处理。

所例示的处理框1696可以将功能请求发送到容器以遵守等待时间约束。该功能请求可以与其他功能请求一起被批量处理。因而，该功能请求和其他功能请求可以被发送到容器。在一些实施例中，如果功能请求无法共享容器或者等待时间约束不准许用于批量处理的时间，则功能请求可能无法被批量处理。

附加注解与示例

示例1600包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：接收各自请求相应功能的执行的多个功能请求，确定来自该多个功能请求的多个可批量处理的功能请求，接收来自该多个可批量处理的功能请求的第一可批量处理的功能请求，确定第一可批量处理的功能请求要被批量处理，等待直到接收到来自该多个可批量处理的功能请求的第二可批量处理的功能请求，确定第一和第二可批量处理的功能请求可以在一起被批量处理，确定第一和第二可批量处理的功能请求的一个或多个等待时间约束，基于该一个或多个等待时间约束来确定用于将第一和第二可批量处理的功能请求发送到同一容器的时间，在所确定的时间将该多个可批量处理的功能请求发送到同一容器，确定该同一容器是温暖的，基于该同一容器是温暖的来确定该多个可批量处理的功能请求要被发送到该同一容器，确定来自多个功能请求调用的不可批量处理的一个或多个不可批量处理的功能请求，以及将该一个或多个不可批量处理的功能请求中的每一者发送到不同的容器，其中可批量处理的功能请求的功能要以串行、并行、或以混合式串行和并行方案来执行。

示例1601包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：接收各自请求相应功能的执行的多个功能请求，以及确定来自该多个功能请求的多个可批量处理的功能请求。

示例1602包括示例1601的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：将该多个可批量处理的功能请求发送到同一容器。

示例1603包括示例1602的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定该同一容器是温暖的，以及基于该同一容器是温暖的来确定该多个可批量处理的功能请求要被发送到该同一容器。

示例1604包括示例1601的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：接收来自该多个可批量处理的功能请求的第一可批量处理的功能请求，确定第一可批量处理的功能请求要被批量处理，等待直到接收到来自该多个可批量处理的功能请求的第二可批量处理的功能请求，以及确定第一和第二可批量处理的功能请求可以在一起被批量处理。

示例1605包括示例1604的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定第一和第二可批量处理的功能请求的一个或多个等待时间约束，基于该一个或多个等待时间约束来确定用于将第一和第二可批量处理的功能请求发送到同一容器的时间，以及在所确定的时间将第一和第二可批量处理的功能请求发送到同一容器。

示例1606包括示例1601的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定来自多个功能请求调用的不可批量处理的一个或多个不可批量处理的功能请求，以及将一个或多个不可批量处理的功能请求中的每一者发送到不同的容器。

示例1607包括示例1601的至少一种计算机可读介质，其中，该可批量处理的功能请求的功能要以串行、并行、或以混合式串行和并行方案来执行。

冗余功能实现

现在转向图17a，示出了冗余功能实现的示例1700，其中功能请求1710被faas系统(例如图4的faas系统400)的编排器1704处置。

在一些情形中，功能可能由于许多因素(例如，计算节点的崩溃)而超时并且永远无法完成。例如，在被触发时，原始功能1712可以通过一系列操作(例如，认证、授权、预启动资源可用性等)，其中编排器1704可以标识计算节点1706c并将计算节点1706c指派给原始功能1712。然而，不同的平台可具有对于请求原始功能1712的faas服务的客户端而言未知且不透明的独特的特性(例如，虚拟化层等)和资源。例如，原始功能1712可能发现它自身正在计算节点1706a的具有足够促成及时执行的未被订阅的资源的温暖容器上运行。在其他情形中，原始功能1712可以在计算节点1706a的同样在繁忙平台上运行但不具有促成执行的足够资源的冷容器上执行。此外，原始功能1712可进一步消耗其性能也是可变的其他服务。作为结果，在原始功能1712实际上将继续执行，完成执行，并且进一步地原始功能1712将以及时的方式完成方面存在有限的确定性。

例如，如果原始功能1712超过可用资源(例如对存储器的动态限制)，则原始功能1712可能不会分派。此外，原始功能1712可能无法以及时的方式指派，或者一旦被指派，可能不清楚原始功能1712是否将在准许的时间限制内完成执行。

在一些情形中，原始功能1712可以完成，但要求多次串行重试。因而，原始功能1712可能一次接着一次地被产生若干次，直到原始功能1712最终完成。在客户端处完成此类串行重试对于确保完成而言是既昂贵又困难的，因为客户端对于导致成功或失败的因素不具有控制。用于成功结果的测试和重试同样使得请求方处的编程复杂化。

一些功能可以被认为具有对成功的高要求，并且因此未完成或延迟完成的风险可能是无法接受的。如下文所讨论的，编排器1704可以通过跨多个计算节点1706a-1706c的冗余功能执行来缓解未完成或延迟完成的概率。例如，原始功能1712的冗余功能1708a、1708b可以被产生并且在不同节点1706a、1706b处执行。

如图17a中所例示的，事件处置api代理1702可以将事件调用路由到功能。在1700的示例中，api代理1702可以经由例如api来生成功能请求1710。功能请求调用1710可以被提供给编排器1704。功能请求1710可以是用于执行原始功能1712的请求。编排器1704可以分析功能请求1710。详细来说，编排器1704可以确定是否要提供冗余功能执行。此类确定可基于原始功能1712是否满足质量阈值。该质量阈值可以基于用户请求(例如，令牌、类等)、服务质量(qos)度量、或服务水平协议。

在图17a的示例中，编排器1704可以确定原始功能1712满足质量阈值，并且因此要通过冗余功能执行方案来缓解原始功能1712的未完成或未及时完成的概率。冗余功能执行方案可包括产生冗余功能1708a、1708b。在一个示例中，冗余功能1708a、1708b中的每一个可以是原始功能1712的相同副本，但原始功能1712的各实现可以针对1708a、1708b处的较慢但有保证的执行来可任选地定制等。例如，这可以通过使用不同的迭代策略来实现，包括基于对于有保证的功能执行而言关键的资源的可用动态利用水平的预测性、主动性和反应性测量。例如，128mb的功能可以在预设有256mbram的容器上运行。功能可以在预设有256mbram的容器上运行。作为另一示例，功能可以伴随较长的超时来运行。

如所例示的，原始功能1712和冗余功能1708a、1708b可以被提供给不同的计算节点1706a-1706c。因此，可以缓解功能超时或未完成的概率。由此，存在通过冗余功能1708a、1708b和原始功能1712中的一者在预定时间量内完成的增大的概率而实现的增强的可靠性。

一旦原始功能1712和冗余功能1708a、1708b中的一者完成执行，编排器1704或另一机制就可以取消原始功能1712和冗余功能1708a-1708b中未完成功能的执行。因而，可以通过取消来高效地管理资源。

在一些实施例中，功能请求1710可包括指定功能是否应当被保证的字段。因而，faas架构的用户(诸如客户端)可以能够指定功能何时应当被保证。在一些实施例中，编排器1704可包括被保证的功能的白名单，并且在执行期间产生那些功能的多个副本。

在一些实施例中，冗余功能1708a、1708b可以具有与原始功能1712非交叠的执行。例如，计算节点1706c可以提供原始功能1712的执行的进度报告。该进度报告可以指示原始功能1712的已完成操作的数目、当前执行的代码行等。如果该进度报告指示原始功能1712被延迟或者可能超时，则编排器1704可以在原始功能1712开始执行之后的某一时间产生冗余功能1708a、1708b。

在一些实施例中，编排器1704可以确定对于原始功能1712的执行而言可能需要的资源要求。编排器1704可以基于资源的可用动态利用测量来确定资源要求。在一些实施例中，诸如从各个遥测源(例如，从计时器、功能或调试日志、以及性能监视器)收集的历史信息可以被用于估计每一功能的执行时间和/或资源要求，其接着可以被用于通知功能的将来调用的调度。对于更多细节，参见图24a和图41a的讨论。编排器1704可以基于资源要求来确定是否要产生冗余功能1708a、1708b。例如，冗余功能1708a、1708b可以响应于计算节点1706c可能缺少用于完成原始功能1712的执行的足够资源或无法满足用于完成原始功能1712的执行的资源要求的标识而被产生。例如，在被原始调度时，计算节点1706c可具有用于执行原始功能1712的足够资源。

然而，如果计算节点1706c在资源方面降级，则计算节点1706c可能缺少用于执行原始功能1712的足够资源。例如，如果计算节点1706由于过热而需要扼流，或者更新、更高优先级的功能被指派到计算节点1706c(这迫使资源的充分分配)，则用于原始功能1712的执行的可用资源可能减少。在一些实施例中，可以作出原始功能1712将要求超出阈值的特定量的资源的标识，并且因此可能难以在特定服务器(诸如计算节点1706c)上维持。在一些实施例中，原始功能1712和冗余功能1708a-1708b中的每一者可以由编排器1704调度为在同一时间开始执行。例如，原始功能1712和冗余功能1708a、1708b可以被调度为响应于原始功能1712满足质量阈值的标识来执行，从而在几乎同一时间开始执行或者对于原始功能1712和冗余功能1708a、1708b中的每一者而言尽可能快地开始执行。冗余功能1708a-1708b和原始功能1712可具有交叠的执行时间。

在一些实施例中，冗余功能1708a、1708b可以被调度为仅在原始功能1712无法完成执行的情况下执行。例如，编排器1704可以确定原始功能1712已经无法完成执行并满足质量阈值。因此，编排器1704可以确定原始功能1712的多个冗余副本应当被产生作为冗余功能1708a、1708b以缓解第二次未完成情况的出现。

此外，api代理1702或编排器1704可以基于指定的参数来标识原始功能1712的重要性。指定的参数可以由管理员或客户端设置，该指定的参数指定了用于不同功能的不同类型的迭代策略以便获得某种程度的确定性。如上所述，此类策略可包括基于原始功能1712的执行所需的资源的可用动态利用测量的预测性、主动性和反应性测量。一旦原始功能1712运行直到完成，则无论冗余功能1708a、1708b可能处于什么执行阶段，编排器1704都可以取消、丢弃或杀死冗余功能1708a、1708b，藉此节省了非必要的资源消耗。因此，编排器1704可以通过缓解功能失败的概率并确保功能将以及时的方式执行来增强faas功能实现。

图17b示出了冗余faas功能实现的方法1750，且可以由图13a的服务器1302执行，但也可以或结合服务器1302被实现在图4的增强的faas系统400和/或图17a的编排器1704和/或一个或多个模块中作为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

所例示的处理框1752可以接收用于执行原始功能的功能请求调用。该功能请求调用可以源自例如应用或用户设备。所例示的处理框1754可以确定原始功能是否满足质量阈值。如果否，则可以仅执行原始功能。即，可以不产生冗余功能。然而如果是，则所例示的处理框1756可以确定要连同原始功能一起执行一个或多个冗余功能。一个或多个冗余副本中的每一者可以是原始功能的相同副本。所例示的处理框1756可包括在交叠的时间在不同计算节点处执行原始功能和一个或多个冗余副本。此外，所例示的处理框1756可进一步包括在第一时间开始原始功能的执行，并且在第一时间之后的第二时间开始一个或多个冗余副本的执行。在一些实施例中，原始功能和一个或多个冗余副本可以在非交叠的时间执行。在一些实施例中，一个或多个冗余副本可以响应于原始功能无法满足进度阈值或资源要求中的一者或多者的标识来开始执行。

附加注解与示例

示例1700包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：接收用于执行原始功能的功能请求调用，确定原始功能是否满足质量阈值，响应于原始功能满足质量阈值来确定要连同原始功能一起执行原始功能的一个或多个冗余功能，其中一个或多个冗余功能中的每一者是原始功能的副本，在交叠的时间执行原始功能和一个或多个冗余功能，在不同的计算节点处执行原始功能和一个或多个冗余功能，在第一时间开始原始功能的执行，以及在第一时间之后的第二时间开始一个或多个冗余功能的执行，以及响应于原始功能无法满足进度阈值或资源要求的标识而开始一个或多个冗余功能的执行。

示例1701包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：接收用于执行原始功能的功能请求调用，确定原始功能是否满足质量阈值，以及响应于原始功能满足质量阈值来确定要连同原始功能一起执行一个或多个冗余功能，其中一个或多个冗余功能中的每一者是原始功能的副本。

示例1702包括示例1701的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在交叠的时间执行原始功能和一个或多个冗余功能。

示例1703包括示例1701的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在不同的计算节点处执行原始功能和一个或多个冗余功能。

示例1704包括示例1701的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在第一时间开始原始功能的执行，以及在第一时间之后的第二时间开始一个或多个冗余功能的执行。

示例1705包括示例1701的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：响应于原始功能无法满足进度阈值或资源要求的标识而开始一个或多个冗余功能的执行。

faas和/或afaas功能的迭代执行

一些任务可触发faas和/或afaas功能的迭代执行。虽然下文参考faas，但是将理解afaas功能也可以被类似地执行。

faas功能可以调查关注的不同空间或区域。例如，投标匹配任务可以探索各种出价组合以试图找到具有最优惠条款的出价。各种组合可以通过迭代faas功能来探索。作为示例，faas功能可能需要重复地迭代以执行投标匹配过程。例如，如果出价的条款包含要求更改投标或高于其他出价的款项，则一个或多个功能可能需要迭代地操作。作为另一示例，在启用人工智能的边缘服务中，直到推理具有落在可接受风险准则内的相关联的置信度量，该推理才可被标识为解决方案。

在一些情形中，迭代执行可以通过使迭代控制动态地可用脚本编写或可变以计及上文描述的各种动态条件而受到支持，因为用于完成迭代任务的条件可能是被动态地指定的。因而，在某些上下文中的faas功能以动态控制来迭代地操作。然而，迭代faas功能有时候在无法达到用于完成的动态条件的情况下不必要地继续操作。例如，假设存在两个搜索空间，每一搜索空间由不同的faas功能来探索。在某一时间量之后，可能变得显而易见的是，faas功能中的一者正在探索不可能产生切实可行的解决方案的搜索子空间。使这样的faas功能不必要地操作是低效的，因为该faas功能消耗可以被分配给更有可能产生切实可行的解决方案的其他faas功能的资源。此外，faas功能可能无法达到终止条件(例如，切实可行的解决方案)并且继续操作直到时间到了。因此，等待时间被增加，而资源被低效地分配。

搜索空间可以是切实可行的解决方案或答案区域，搜索方案或过程可以在其中探索以寻求满足搜索准则的可能解决方案或答案。例如，搜索空间可以被用于描述搜索可以被认为是切实可行的概率、参数、算法、方案、值或访问或时间约束的整个集合。在一个特定示例中，对于超级计算机下棋，搜索空间可能非常大，但是对于在膝上型计算机或平板计算机上运行的与云断开连接的程序而言，搜索空间可能在评估深度、评估时间、或要评估的替换步的数目等方面受约束。尽管上文引用搜索空间，但是下文将引用“解决方案空间”，其中搜索空间是解决方案空间的一个示例。解决方案空间可以是要在其中标识解决方案的空间。

转向图18a和18b，增强的调度器1820被提供以生成用于faas服务的功能生成图1800。增强的调度器1820可以基于条件被满足来取消对功能生成图1800的解决方案空间的资源分配或对资源分配重排定优先级，该条件例如解决方案空间(例如，探索的特定集合)不太可能产生切实可行的解决方案的概率。这么做可以增强资源分配，并且减少从切实可行的解决方案空间中找到切实可行且接近最优的解决方案的定时。

图18a例示了功能生成图1800。调度器1820(如图18b中所示)可包括生成功能图1800并实现用于执行功能图1800以试图寻找足够有价值的解决方案的对元任务进行调度、取消和重排定优先级的各种硬件或软件实现。例如，调度器1820可以是使用线程构建块构建的分支和边界操作；或者它可以是sql查询优化器等。任务1812可以产生功能a1802、功能b1804、功能c1806、功能d1808和功能e1810。在以下的描述中，为简明起见，功能a1802、功能b1804、功能c1806、功能d1808和功能e1810可以被统称为“所产生的功能”。

功能生成图1800是对于所产生的功能以并行或串行操作的调度的数据表示。所产生的功能可以是不同但有关的功能。功能c1806可取决于来自功能a1802的数据来执行，且因此取决于功能a1802。由此，功能a1802和功能c1806可以被认为是功能生成图1800的第一分支1814。同样地，功能d1808可取决于来自功能b1804的数据来执行，且因此取决于功能b。功能b1804和功能d1808可以被认为是功能生成图1800的第三分支1818。功能e1810可以不需要来自另一功能的数据来操作。功能e1810可以被认为是功能生成图1800的第二分支1816。第一、第二和第三分支1814、1816、1818中的每一者可包括至少一个迭代功能，且被认为是用于潜在的解决方案或结果的分开的解决方案空间和/或探索可能性。为了被认为完成，任务1812可能仅采用来自第一、第二和第三分支1814、1816、1818中的一者的最佳的可能解决方案或结果

如所例示的，第一、第二和第三分支1814、1816、1818可以彼此不同但有关。即，第一、第二和第三分支1814、1816、1818可以表示迭代探索的不同的搜索解决方案空间或区域。第一、第二和第三分支1814、1816、1818可以例如通过不共享信息来操作来独立地操作，且因此可以被认为是分开的。然而，第一、第二和第三分支1814、1816、1818可以是有关的，因为第一、第二和第三分支1814、1816、1818中的一者可以导致其本身或第一、第二和第三分支1814、1816、1818中的另一者的去优先级或取消。

例如，如果第一、第二和第三分支1814、1816、1818中的一个分支达到取消条件(其可以被认为是去优先级条件)，则调度器1820可以终止这个分支。在另一示例中，对第一、第二和第三分支1814、1816、1818中的一个分支的资源分配可以由调度器1820基于正达到去优先级条件来修改。例如，如果调度器1820标识第一、第二和第三分支1814、1816、1818中的一个分支具有比第一、第二和第三分支1814、1816、1818中的另一分支低得多的成功概率，则去优先级条件可以被认为被满足。此外，调度器1820可以减少对一个分支的资源分配并且增加对另一分支的资源分配。

例如，每一解决方案空间可以表示不同的解决方案。随着解决方案空间在搜索尺寸上变窄或缩减，潜在解决方案的数目相应地降低，从而暗示可以在有限量的计算力或时间内达成解决方案。如果第一、第二和第三分支1814、1816、1818中的一个分支通过迭代缩减解决方案空间(缩窄解决方案的可能选项)，则该分支可能正趋向于成功。作为对比，如果第一、第二和第三分支1814、1816、1818中的另一分支增大了解决方案空间(增加了解决方案的可能选项)或维持相同的解决方案空间尺寸，则该另一分支可能正趋向于失败和/或可能在穷尽当前优先的探索会导致解决方案的可能性之后正在产生要探索的替换解决方案。该另一分支因此可能基于失败趋势而达到去优先级条件。在一些实施例中，解决方案空间尺寸(解决方案选项)的比较可导致达到去优先级条件。例如，如果第一、第二和第三分支1814、1816、1818中的一个分支的一个解决方案空间与第一、第二和第三分支1814、1816、1818中的另一分支的另一解决方案空间相比已经通过迭代以更快地速率缩减，则该另一分支可以被认为满足去优先级条件。

具体地，如上所述，所产生的功能之一可能达到去优先级条件。去优先级条件可以指示第一、第二和第三分支1814、1816、1818中的一者或多者可以被去优先级。去优先级可以意味着第一、第二和第三分支1814、1816、1818中的一者或多者被认为正在探索不太可能产生对该任务要解决的问题的切实可行的解决方案的区域或空间，或者可能要求比某一其他所产生的功能更多的资源或时间。如果调度器1820对第一、第二和第三分支1814、1816、1818中的一个分支去优先级，则较少的资源可以被分配给该分支，或者可以通过挂起/终止/松开包括该分支的任何所产生的功能来挂起/终止/松开该分支。去优先级条件可以是在所产生的功能之一标识终止条件从而导致一个所产生的功能或另一所产生的功能的终止时。因而，可以通过避免对于任务而言不太重要或不相关的功能的执行来达成高效的资源分配。

例如，假定功能d1808达到去优先级条件。第三分支1818可以被终止，这可以包括停止功能d1808和/或功能b1804的执行。在一些实施例中，对第三分支1818的资源分配被减少，而非终止第三分支1818。例如，对功能d1808和/或功能b1804的资源分配可以被减少。在一些实施例中，去优先级条件可以通过功能d1808产生的值、功能d产生的解决方案的置信区间、功能d的成功可能性的测量、功能d是否正在逼近潜在的解决方案等等来标识。

如图18b中所例示的，增强的faas系统1832可包括调度器1820。如已经描述的，调度器1820可以生成图18a的功能生成图1800，根据功能图1800来调度并且相应地取消所产生的功能。

详细来说，调度器1820可以根据功能生成图1800来调度和监视所产生的功能的执行。功能a的迭代执行1822、功能b的迭代执行1826、功能c的迭代执行1824、功能d的迭代执行1828和功能e的迭代执行1830分别对应于图18a的功能a1802、功能b1804、功能c1806、功能d1808和功能e1810。

调度器1820可以在功能生成图1800的执行期间标识去优先级条件(例如，终止条件)并且基于去优先级条件来停止或挂起执行。例如，调度器1820可以终止或挂起所产生的功能中的一者或多者，并且停止和/或暂停这些所产生的功能的任何进一步的功能实例化。调度器1820可以利用硬件队列管理器和多播来这么做。

详细来说，功能a的迭代执行1822包括fa1-fan，它们是功能a1802的迭代。功能a的迭代执行1822可以完成，并且接着功能c的迭代执行1824可以开始。同样地，功能b的迭代执行1826可以完成，并且功能d的迭代执行1828可以开始。在一些实施例中，可执行同时执行。例如，功能a的迭代执行1822可以与功能c的迭代执行1824并发地进行。此外，功能b的迭代执行1826可以与功能d的迭代执行1828并发。

在功能c的迭代执行1824期间，调度器1820可以标识终止功能c的迭代执行1824的去优先级条件。此类去优先级条件可包括第一分支1814且具体地功能c1806不太可能产生切实可行的解决方案的标识。因而，功能c的迭代执行1824仅执行了一次迭代fc1。在功能c的迭代执行的取消或挂起之后，分配给功能c的迭代执行1824的资源可以被重分配给其他执行。例如，功能e的迭代执行1830可具有增加的资源分配和/或功能d的迭代执行1828可具有增加的资源分配。

在一些实施例中，代替取消功能c的迭代执行1824，调度器1820可以减少功能c的迭代执行1824的资源分配。在一些实施例中，调度器1820可以将资源分配从功能c的迭代执行1824重分发到功能e的迭代执行1830和/或功能d的迭代执行1828。在一些实施例中，可以基于所产生的功能中的一者或多者具有最大成功机会和/或相比于仍然继续操作的所产生的功能中的其他功能具有更大成功机会的可能性来将资源重分配给所产生的功能中的该一者或多者。这么做可以减少功能e的迭代执行1830和/或功能d的迭代执行1828的等待时间，并且还可减少标识任务的解决方案的等待时间。然而，功能c的迭代执行1824的等待时间可能增大，但是在功能c的迭代执行1824所呈现的较低成功可能性的情况下这可以被认为是一种可接受的折衷。

在一些实施例中，功能c的迭代执行1824可以被重排定优先级。例如，在重排定优先级条件被满足的情况下，功能c的迭代执行1824可以被重排定优先级，以使得功能c的迭代执行1824被恢复和/或具有增加的资源分配。例如，重排定优先级条件可以是功能c的迭代执行1824比所产生的功能中的其他功能更有可能产生切实可行的结果的指示。在一些实施例中，重排定优先级条件可以是另一所产生的功能(例如功能d的迭代执行1828)的成功可能性降低的标识。

在一些实施例中，所产生的功能的迭代执行在不同节点和/或容器处进行。例如，功能a的迭代执行1822可以在不同的节点和/或不同的容器处进行。fa1可以在第一节点处在第一容器中执行，而fan可以在第二节点处在第二容器处执行。

如已经描述的，调度器1820可以通过终止所产生的功能和/或减少对不太成功的解决方案空间的资源分配来减少等待时间并且具有增强的资源管理，如上所述。例如，响应于去优先级条件的标识高效地解除分配资源。

迭代执行控制可以是动态地可用脚本编写的或可变的，因为用于完成迭代任务的条件可能被动态地指定。因而，调度器1820可以探索由第一、第二和第三分支1814、1816、1818表示的不同策略以及具体地第一、第二和第三分支1814、1816、1818的所产生的功能。第一、第二和第三分支1814、1816、1818可以是根据动态提示、最近观察到的模式和模式转移、约束变动等来确定的不同的搜索策略。

例如，调度器1820可以在有限量的时间内和任何给定时间的功率预算内标识最佳推理。为此，如果时间窗口足够小或无法满足阈值，和/或如果计算预算足够小或无法满足阈值，则调度器1820可以使用低精度策略。在如图18b中所例示的探索第一、第二和第三分支1814、1816、1818之后，调度器1820可以在消除诸如上述第一分支1814之类的解决方案空间之后对稍后的迭代使用较高精度。因而，调度器1820可以通过第一、第二和第三分支1814、1816、1818来发起若干并行、低成本搜索，并且接着响应于第一、第二和第三分支1814、1816、1818中的一些分支将产生更高产的结果的标识来取消第一、第二和第三分支1814、1816、1818中的另一些分支。如已经描述的，第一、第二和第三分支1814、1816、1818中的一个分支的取消可能意味着包括该被取消分支的所产生的功能的取消。

因而，调度器1820可以高效地取消或减少对功能a的迭代执行1822、功能b的迭代执行1826、功能c的迭代执行1824、功能d的迭代执行1828和功能e的迭代执行1830中被去优先级的功能的迭代执行的资源分配。去优先级可以意味着去优先级的迭代功能被认为正在探索不太可能产生对任务所解决的问题的切实可行的解决方案的区域或空间。例如，一些实施例可包括用于对功能a的迭代执行1822、功能b的迭代执行1826、功能c的迭代执行1824、功能d的迭代执行1828和功能e的迭代执行1830的此类动态迭代启动和取消的各种元编程支持。如果解决方案子空间变为被临时去优先级，则用于探索该解决方案子空间所消耗的解决方案空间的资源可以被动态地解除分配，例如，通过将数据移出高速缓存层直到该解决方案子空间被重排定优先级。此外，所产生的功能的取消可以被自动生成，以使得资源可以快速地从不太重要的功能或工作被解除分配，并被分配给其他较高优先级的工作或所产生的功能。

在一些示例中，实现灵活多播拓扑，其中来自所产生的功能处的一次迭代的数据(和事件)可以被自动移到可以本地进行或可以不本地进行的该所产生的功能(或另一所产生的功能)的另一迭代。因而，该拓扑实现用于取消所产生的功能或对所产生的功能重排定优先级的高效通信策略。

此外，一些实施例可具有增强的多播拓扑，其推广各种点到点能力以满足网络功能虚拟化性能需求。例如，一些实施例可以实现灵活多播拓扑，以使得在所产生的功能和任务在基础设施的一部分中被产生而在该基础设施的另一部分中被取消时，该通信拓扑以低通信开销来适配。例如，在边缘计算中，当请求方移动客户端或移动目标(例如，基站或消费者场所装备)改变位置时，一些实施例可以以高效的方式来修改不同节点、容器等之间的多播布置以使对应迭代的所产生的功能重分布。

例如，在一些实施例中，调度器1820可以标识移动客户端和/或移动目标的位置。当移动客户端和/或移动目标移动位置时，所产生的功能的迭代执行可以被移动到不同的容器和/或节点以保持在移动客户端和/或目标的预定距离之内。这么做可以减少通信等待时间，并且可以通过上述灵活多播基础设施来达成。此外，调度器1820可以知悉各个容器和/或节点，以使得调度器1820可以控制所产生的功能的执行、资源分配和取消。此外，用于运行元程序的能力可以进一步被移到硬件(诸如硬件队列管理器)内并且被提供给平台软件，以使得所产生的功能可具有更快速的执行以及在需要的时候的高效取消。硬件队列管理器的实施例是平台硬件特征，其可以从多个实体中的第一实体(例如，实体可以是任务、进程、容器、虚拟机等)接收控制操作或对操作的数据移动请求，以及在认证可以在不违背适用的安全策略且可任选地不迫使第一请求方实体等待直到该操作已经在多个实体中的第二实体(例如，另一任务、另一进程、另一容器、另一虚拟机等)中完成的情况下执行所请求的操作之后，在第二实体中执行所请求的操作。

图18c示出了faas功能实现的方法1870，且可以由图13a的服务器1302执行，但也可以或结合服务器1302被实现在图4的增强的faas系统400和/或图18b的调度器1820或一个或多个模块中作为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

所例示的处理框1872可以标识要被执行的多个功能。该多个功能可以迭代地执行。所例示的处理框1874可以响应于去优先级条件被标识来对该多个功能中的一者或多者去优先级。例如，所例示的处理框1874响应于去优先级条件被标识来取消该多个功能中的一者或多者的执行。所例示的处理框1874还可以响应于去优先级条件被标识来减少该多个功能中的一者或多者的资源分配。所例示的处理框1876可以响应于去优先级条件被标识来增加对该多个功能中未被去优先级的一者或多者的资源分配。

方法1870可以通过终止和/或减少对不太成功的解决方案空间(例如，该多个功能中的一者或多者)的资源分配来减少等待时间并具有增强的资源管理，如上所述。例如，响应于去优先级条件的标识来高效地解除分配资源，如参考所例示的处理框1874所描述的。

附加注解与示例

示例1800包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：标识要被执行的多个功能，响应于去优先级条件被标识来对该多个功能中的一者或多者去优先级，响应于去优先级条件被标识，减少该多个功能中的一者或多者的资源分配或取消该多个功能中的一者或多者的执行，以及增大对该多个功能中未被去优先级的一者或多者的资源分配，其中该多个功能的各功能要迭代地执行。

示例1801包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：标识要被执行的多个功能，以及响应于去优先级条件被标识来对该多个功能中的一者或多者去优先级。

示例1802包括示例1801的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：响应于去优先级条件被标识，取消该多个功能中的一者或多者的执行。

示例1803包括示例1802的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：响应于去优先级条件被标识，减少该多个功能中的一者或多者的资源分配。

示例1804包括示例1801的至少一种计算机可读介质，其中该多个功能的各功能要迭代地执行。

示例1805包括示例1801的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：增大对该多个功能中未被去优先级的一者或多者的资源分配。

具有共用数据存储的增强的faas架构

faas环境中的通信等待时间可能呈现出显著的开销。例如，一些faas环境可包括数千个功能，其中对应的数据在各节点之间被传递以实现长期存储和/或执行。此外，功能可以被认为是“无状态的”。由此，使创建数据的功能的执行能够存活的数据存储可能提出特别的挑战。一些实施例增强对此类数据的高速缓存以供将来重用。

例如，考虑可以是节点的数据库服务器。该节点(数据库服务器)相对于执行功能的执行节点而言可以是远程的。数据库服务器可以存储该功能可用于执行的数据。从执行节点对远程数据库服务器的数据访问可能是昂贵的，且由此数据可以被移动到执行节点或被移动到邻近执行节点。此类数据传递可能是高等待时间且资源密集的，具体地取决于数据的特性和大小。例如，不仅会引发浪费的往返输入/输出，而且会将数据的自然格式从静态编码格式修改为使用中编码格式，并且反之亦然。因而，编组成本以及用于在数据的静态编码格式和使用中编码格式之间改变的成本被增加。

现在转向图19a，例示了具有共用数据存储的增强的faas架构1900。示例1900可包括图4的增强的faas系统400。一些实施例可以通过利用共用数据存储1910(其可以是暂时数据存储)来存储供一个或多个功能重用的数据来增强效率。例如，功能f1可以产生要被其他功能使用的共用数据。共用数据可以被存储在共用数据存储1910中。在功能f1完成执行之后，共用数据可以保持被存储在共用数据存储1910中。之后，诸如功能f2等的其他功能可以开始执行并访问共用数据。例如，如果功能f2在第一功能f1完成之后开始执行，则功能f2可以被实例化到邻近和/或包括共用数据存储1910的一节点，诸如执行节点1904。

因此，共用数据可以保持在共用数据存储1910中，而非被驱逐。此外，共用数据的格式可以出于安全原因被加密，但是不能以其他方式被改变。因而，以上实现可以减少io传递和数据编码格式修改，从而减少等待时间并增强资源使用。

控制节点1902可以在时间t0调用功能f1，如进程1912所指示的。功能f1可以在节点1904上执行。节点1904可以与本地数据存储1906处于通信。在一些实施例中，本地数据存储1906可以是执行节点1904的一部分。在一些实施例中，本地数据存储1906和执行节点1904是同一计算设备(诸如服务器)的一部分。如所例示的，本地数据存储1906包括至少两个数据存储或分区，包括共用数据存储1910和特定数据存储1928。

功能f1可以在功能f1在执行节点1904的容器中执行时生成数据。该数据中的至少一些数据可以被称为共用数据。共用数据可以被其他功能重用。例如，控制节点1902可以生成功能生成图，诸如图18a的功能生成图1800。在一些实施例中，控制节点1902的操作可以可任选地由接收自编程人员或云服务提供商的指令来引导。控制节点1902可以分析功能生成图来确定各功能的相互依赖性以及例如一个功能是否要基于另一功能生成的数据来操作。控制节点1902可以控制数据是被存储在共用数据存储1910中还是特定数据存储1928中。在一些实施例中，数据是被存储在共用数据存储1910中还是特定数据存储1928中的决策可服从来自编程人员或云服务提供商的附加输入(例如，提示、指令等)，并且编程人员或云服务提供商可以时不时地改变这些输入(例如，提示或指令)。

在一些实施例中，控制节点1902可以确定功能f2将消耗由功能f1生成的数据。因而，控制节点1902可以将功能f1生成的至少一些数据是共用数据的命令或消息传递到执行节点1904。例如，当功能f1在时间t0被调用时，控制节点1902可以指令执行节点1904将功能f1生成的数据作为共用数据来存储。在一些实施例中，仅功能f1的数据子集(例如，最终计算或结论数据)而非功能f1的全部数据可以被认为是共用数据。数据子集可以是被标识为可由功能f2重用的数据。被标识为不可被功能f2重用的其他数据可以被丢弃。

执行节点1904可以实例化功能f1并且分配来自共用数据存储1910的数据存储。功能f1因此可以将共用数据存储在共用数据存储1910中，如由进程1914指示的。在功能f1完成执行之后，代替将共用数据发送到控制节点1902，共用数据可以停留在共用数据存储1910中。例如，代替立即将共用数据从共用数据存储1910中移除，共用数据可以保持被存储在共用数据存储1910中。

共用数据可以被给予存活时间策略，其描述了共用数据的存活时间。存活时间可以由访问共用数据的其他功能延长。存活时间可以在每一次一个新的功能访问该共用数据时被延长一固定量(或一可变量，如根据基于过去历史从策略或试探法中所确定的)。在一些实施例中，共用数据可服从最大存活时间，在经过最大存活时间之后共用数据将从至少共用数据存储1910中被自动驱逐，并且进一步从本地数据存储1906中被自动驱逐。如果共用数据在功能f1完成执行之后保持未被访问，则该共用数据可以在存活时间期满之后被驱逐到控制节点1902，而无需对存活时间的任何调整。本地数据存储1906和/或执行节点1904可以实施存活时间策略。

在一些实施例中，存活时间策略可以对照安全性要求来平衡。例如，如果本地数据存储1906被维护在通过物理入侵可被容易破坏的边缘设备中，则存活时间可以被设置成低值。此外，如果共用数据具有高安全性要求，则存活时间可以被设置为低值。

此外，功能f1和/或本地数据存储1906可以对共用数据加密。通过这么做，可以增强安全性，以使得共用数据可以仅被经授权的功能访问。

功能f1、执行节点1904和/或本地数据存储1906可以生成描述符(唯一标识符等)，其描述共用数据被存储在哪里以及共用数据是否被加密。此外，如果共用数据出于安全目的被加密，则该描述符可包括用于访问该共用数据的解密协议。例如，描述符可包括用于解密共用数据的解密密钥。描述符可以被提供给控制节点1902，控制节点1902可以在恰适的时候将描述符传递给其他功能。

在功能f1完成执行之后，控制节点1902可以在时间t2调用功能f2，如进程1924所指示的。执行节点1904可以执行功能f2。功能f2可以接收由功能f1存储的共用数据的描述符。描述符可以准确地描述共用数据的位置以及任何恰适的解密协议。功能f2可以访问被存储在共用数据存储1910中的共用数据，如进程1916所指示的，并且基于共用数据来执行。因而，共用数据的存活时间可以被增加。访问可以意味着功能f2可以读取该共用数据、将新的共用数据添加到该共用数据和/或盖写该共用数据。如上所述，由于共用数据被访问，因此共用数据的存活时间被延长一预定义的值。在一些实施例中，作为存活时间的替换或补充，引用计数器可以被用来防止在功能f2尚未达到其完成时共用数据的不成熟驱逐。

功能f2还可生成仅功能f2将使用的特定数据。该特定数据可以被存储在与共用数据存储1910分开的分区(诸如特定数据存储1928)中，如进程1922所指示的。该特定数据可以在功能f2完成执行时从特定数据存储1928中被自动驱逐，如进程1930所例示的。

功能f2可以在t1(t1的调用时间)之后的时间但在功能f3在t2被调用(如由进程1932所指示的)之前完成执行。在专用于f2的资源被回收时，由功能f2生成的特定数据可以被自动驱逐到控制节点1902，如由进程1930所指示的。控制节点1902可以在不将特定数据存储到长期存储中的情况下放弃特定数据，或者将特定数据存储在数据库节点1908处。

由此，共用数据存储1910可以提供用于在功能f1和f2之间传递数据的临时存储。这么做可以通过将功能f1产生的数据保存到共用数据存储1910中来限制对数据库节点1908的数据库访问(读/写)。此外，图19a中例示的增强的faas架构可具有增强的资源管理协议，因为在本地数据存储1906与控制节点1902之间传递较少的数据并进一步减少了功能f2的等待时间。例如，由于减少的数据移动和输入/输出带宽，功能f2可以以较少的开销且无需等待共用数据的数据传递就开始执行。

共用数据存储1910可以是执行节点1904的本地页高速缓存以允许功能f2访问。详细来说，功能f2在执行节点1904上执行，并因此能够以方便的方式访问执行节点1904的本地页高速缓存。在一些实施例中，数据存储1910可以是存储(文件或块高速缓存)高速缓存、使用页高速缓存和块高速缓存的某种组合的瞬态密钥值存储或文件存储等。

控制节点1902可以在时间t2调用功能f3，如进程1932所例示的。功能f3在执行节点1904上开始执行，并且生成特定数据。特定数据可以被进程1926存储到特定数据存储1928中。在功能f3完成执行之后或者在用于功能f3的容器被拆除或回收时，该特定数据可以通过进程1930被驱逐，并且被控制节点1902丢弃或被存储在数据库节点1908中。

功能f3可以不访问存储在共用数据存储1910中的共用数据。由此，共用数据的存活时间可以不被延长并且可以期满。因而，进程1918可以在功能f2完成之后的预定时间驱逐共用数据。详细来说，共用数据可以从共用数据存储1910中被驱逐并被发送到控制节点1902。控制节点1902可以将共用数据从使用中编码格式修改为静态编码格式，并接着在进程1920中将共用数据存储到数据库节点1908。数据库节点1908可以是长期存储。共用数据也可以被本地数据存储1906修改为静态编码格式。

在一些实施例中，功能f1、f2、f3产生的数据可以被存储在共用数据存储1910中，而不参考对数据的潜在重用。因而，控制节点1902可以不分析功能图来确定功能f1、f2、f3中的哪些可生成可被其他功能f1、f2、f3使用的数据。相反，每一功能f1、f2、f3可以将所生成的数据存储在共用数据存储1910中。数据可以与如上所述的类似方式被处理，并且可以被加密且在对应的存活时间期满之后从共用数据存储1910中被驱逐。

图19b示出了使用由一个或多个faas功能生成的共用数据存储的方法1950，且可由图4的增强的faas系统400和/或一个或多个模块实现为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

所例示的处理框1952可以在第一功能的执行期间将与该功能相关联的第一数据存储在数据存储中，其中第一数据将被一个或多个其他功能使用。例如，第一数据可以被存储在数据存储的高速缓存中，其中数据存储可供一个或多个其他功能访问。所例示的处理框1954可以在第一功能终止之后使第一功能的第一数据保持在数据存储中。例如，响应于第一功能已经完成执行的标识，第一数据可以不被驱逐。所例示的处理框1956可以在第二功能的执行期间允许第二功能访问存储在数据存储中的第一数据。例如，第二功能可以接收指示第一数据的位置的描述符以及访问第一数据所需的任何安全协议。可以使用用于创建描述符来引用数据的任何方法。例如，描述符可包括要被引用的数据被存储在特定位置的指示，并且可以在数据被存储时(例如，由存储器控制器)生成。描述符可进一步包括或指示与第一数据相关联的元数据的位置，其中元数据用于包括在第一数据被加密的情况下用于解密第一数据的适用解密密钥、在第一数据被指纹保护的情况下用于验证第一数据的适用验证码、在第一数据被压缩的情况下用于解压第一数据的解压码等。因而，第一数据可以在第一和第二功能访问数据存储的同时被存储在数据存储中。如上所述，这么做可以通过减少i/o操作、数据传输和数据修改来减少等待时间并增强资源管理。

所例示的处理框1958可以确定第一数据在数据存储中没有被访问的时间段。所例示的处理框1960可以确定该时间段是否满足第一数据的存活时间阈值。如果否，则所例示的处理框1958可以重复以确定第一数据未被访问的时间段。在存活时间阈值被满足时，所例示的处理框1962可以将第一数据从数据存储中驱逐。第一数据的驱逐可包括对第一数据被存储在其中的存储器的解除分配和/或从数据存储擦除第一数据。所例示的处理框1964可以将第一数据存储在第二数据服务器处。第二数据服务器可以是长期数据库存储服务器。

图19c示出了实现和实施faas安全协议的方法1970，且可由图4的增强的faas系统400和/或一个或多个模块实现为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

所例示的处理框1972可以确定由第一功能生成的数据将被存储在共用数据存储中以供其他功能访问。所例示的处理框1974可以在第一功能完成执行之后加密第一数据以使得第一数据是加密的。所例示的处理框1976可以确定第二功能可以访问第一数据。例如，所例示的处理框1976可以标识第二功能的安全授权、第二功能实例化的源头(例如，请求第二功能的执行的服务器、服务或客户端)、第二功能的恶意软件分析、和/或第二功能是否与第一数据兼容。所例示的处理框1978可以解密第一数据以允许第二功能访问第一数据。框1974中的加密和/或框1978中的解密可以使用增强的faas系统300中的硬件和/或软件和/或使用硬件和软件方法的组合通过已知技术(例如经由加密和解密密钥)来执行。方法1970可以增强安全性以降低恶意软件或第三方访问数据的可能性。

附加注解与示例

示例1900包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：在第一功能的执行期间将与第一功能相关联的第一数据存储在数据存储中，其中第一数据要被存储在数据存储的高速缓存中，在第一功能终止之后，将第一功能的第一数据保持在数据存储中，在第二功能的执行期间允许第二功能访问存储在数据存储中的第一数据，确定第一数据在数据存储中未被访问的时间段，确定该时间段是否满足第一数据的存活时间阈值，在该时间段满足存活时间阈值时将第一数据从数据存储中驱逐，响应于该时间段满足存活时间阈值将第一数据存储在第二数据服务器处，将描述符传递到第二功能，其中该描述符指示第一数据的位置并且进一步指示与第一数据相关联的元数据的位置，其中该元数据要包括在第一数据被加密的情况下用于解密第一数据的适用解密密钥、在第一数据被指纹保护的情况下用于验证第一数据的适用验证码、或在第一数据被压缩的情况下用于解压第一数据的解压码中的一者或多者，在第一功能完成执行之后加密第一数据以使得第一数据是加密的，以及解密第一数据以允许第二功能访问第一数据。

示例1901包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：在第一功能的执行期间将与第一功能相关联的第一数据存储在数据存储中，在第一功能终止之后，将第一功能的第一数据保持在数据存储中，以及在第二功能的执行期间允许第二功能访问存储在数据存储中的第一数据。

示例1902可包括示例1901的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定第一数据在数据存储中未被访问的时间段。

示例1903包括示例1902的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定该时间段是否满足第一数据的存活时间阈值，以及在该时间段满足存活时间阈值时将第一数据从数据存储中驱逐。

示例1904包括示例1903的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：响应于该时间段满足存活时间阈值将第一数据存储在第二数据服务器处。

示例1905包括示例1901的至少一种计算机可读介质，其中第一数据要被存储在数据存储的高速缓存中。

示例1906包括示例1901的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：将描述符传递到第二功能，其中该描述符指示第一数据的位置并且进一步指示与第一数据相关联的元数据的位置，其中该元数据要包括在第一数据被加密的情况下用于解密第一数据的适用解密密钥、在第一数据被指纹保护的情况下用于验证第一数据的适用验证码、或在第一数据被压缩的情况下用于解压第一数据的解压码中的一者或多者。

示例1907包括示例1901的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在第一功能完成执行之后加密第一数据以使得第一数据是加密的，以及解密第一数据以允许第二功能访问第一数据。

功能即服务环境可具有等待时间与资源开销之间的折衷。预设冷容器可包括大规模、高等待时间的数据传输以及基于数据的容器的构造。因而，预设冷容器可能是高等待时间操作。作为对比，维持温暖容器可以是低等待时间操作，因为以上的数据传输和构造可以被避免。维持温暖容器可消耗在延长的时间段内保持空闲的过多的计算资源，并且具有显著的存储器印记。例如，温暖容器可以在等待功能以供执行的同时保持未被利用和空闲。此外，温暖容器可具有极大的资源分配以执行抵达的功能，同时保持空闲并等待此类功能。

具有不同模式的增强的faas服务器架构

图20a示出了增强的faas服务器架构2000，其中服务器2002包括智能网络接口卡(nic)2004，其包括faas管理逻辑2006a。在另一实施例中，逻辑2006a可以作为硬件被实现在服务器架构2000中，例如被实现在处理器中、被实现在基板管理控制器中、被实现在加速器和/或fpga中等。服务器2002可进一步包括faas管理逻辑2006b，其结合faas管理逻辑2006a来操作和/或与其协调地来操作。faas管理逻辑2006b可以是服务器2002的os驱动器或智能中间件。faas管理逻辑2006a、2006b可以实施高速缓存策略方面的改变，以使得faas服务器架构2000通过将更多的存储器资源用于与专用faas相关联的数据/对象来适配不断增长的faas工作负载。在一些实施例中，服务器2002可仅包括faas管理逻辑2006a、2006b中的一者而非这两者。因此作为示例，仅faas管理2006b可以被包括来改变高速缓存策略。此类改变可以通过例如对控制在通用或专用处理器中实现的高速缓存策略的一个或多个配置寄存器进行编程来实施。专用高速缓存也可适用于软件管理的资源，诸如页高速缓存；相应地，操作系统和运行时软件可以将物理页池细分为至少两个子池：一个通用，而一个专用于faas，其中根据该系统是要在专用faas模式、通用模式还是混合模式中操作来针对各个子池具有不同的大小。由此，如参考图20a-20d使用的高速缓存可包括软件资源高速缓存和硬件高速缓存两者。将理解，软件资源高速缓存和硬件高速缓存两者要用于(直接或间接)反映对底层存储器的访问。

faas管理逻辑2006a、2006b可以确定是否要在三个或更多个不同模式中操作服务器2002，该不同模式包括专用faas模式、通用模式和混合faas模式。在图20a中例示的实施例中，服务器2002在混合faas模式中。在混合faas模式中，仅高速缓存2008、2010、2012中的一些高速缓存被置于专用faas模式中，而另一些高速缓存被置于通用模式中。在专用faas模式中，高速缓存2008、2010、2012中的每一者均专用于faas模式。高速缓存2008、2010、2012可包括软件资源高速缓存和硬件高速缓存两者。

服务器架构2000可以通过用于平台(例如服务器)的混合和专用faas模式来平衡等待时间和资源考量。在混合faas模式中，一个或多个高速缓存(诸如专用faas高速缓存2008、2010)可以被用于保存仅与一个或多个功能相关联的数据对象。替换地，专用faas高速缓存2008或2010可以实现“软优先级”，以使得与一个或多个功能相关联的数据对象被赋予较大的高速缓存驻留期。此类高速缓存驻留期调整可以通过例如对于faas功能高速缓存的数据相比于普通应用高速缓存的数据采用不同的老化策略来执行。因而在一些实施例中，专用faas高速缓存2008、2010可以使faas数据对象的优先级高于非faas数据，以使得faas数据对象更有可能被存储在专用faas高速缓存2008、2010中。在一些实施例中，专用faas高速缓存2008、2010可以存储用于构造容器的至少一些数据。在一些实施例中，专用faas高速缓存2008、2010可以被专用于存储初始化容器所需的容器数据。

一些实施例可以减少用于冷容器初始化的等待时间，因为不同节点之间的数据传输可以被避免，并且容器构造可基于本地高速缓存的数据而开始。即，容器和功能初始化可以被加速。如下文所述，功能的初始化可包括容器的构造以及在容器中开始功能的执行。容器的初始化和/或构造可包括可被高速缓存的独立于功能数据的部分的构造以及不可被高速缓存的容器的附加、特定于功能数据的部分的构造两者。

一些实施例可对容器采用“即时”办法。如上所述，容器的启动等待时间被减少。在需要时，容器可以从专用faas高速缓存2008、2010中的数据被快速地“即时”再次初始化以满足函数的等待时间要求。因而，用于容器初始化的“即时”办法可以被用于减少温暖容器使用，因为温暖容器(例如，并未正在执行功能且正在等待功能的容器)的数目可以被减少。

减少温暖容器使用可以通过减少的温暖容器资源印记来增强资源分配。例如，由于在较少或较小的温暖容器可以被维持处于待命状态时，资源可以被释放并专用于正在执行功能的活跃容器(其可以被称为热容器)。由此，可以以较少的资源来支持较多的功能，通过增加的资源分配来更快地完成执行，并且维持可接受的等待时间要求。

如图20a中所例示的，服务器2002可包括三个高速缓存2008、2010、2012。在混合faas模式中，两个高速缓存2008、2010可作为专用faas高速缓存来操作。专用faas高速缓存2008、2010可以存储用于构建一个或多个容器的初始化数据。该一个或多个容器可以在服务器2002中在本地构建。因而，代替从远程节点接收用于置备容器的全部数据，服务器2002可以访问专用faas高速缓存2008、2010。此外，服务器2002可以不必维持用于一些功能的温暖容器，藉此减少了对温暖容器的硬件组件(诸如加速器、存储器、fpga、处理器等)的资源分配。因而，服务器2002可以通过增强的资源分配和“即时”容器初始化办法来支持更活跃的(热)容器并加速功能执行。

在一些实施例中，专用faas高速缓存2008、2010可以仅存储用于发起容器所需的总数据集的一部分。例如，服务器2002可以以串行顺序来构建容器的若干不同组件。专用faas高速缓存2008、2010中的初始化数据可以是用于构建容器的起始组件的数据，其中用于构建其他稍后续组件的数据从远程节点被传送到服务器2002。由此，容器可以基于存储在专用faas高速缓存2008、2010中的初始化数据来启动构建过程的起始部分。服务器2002可以与构建过程的起始部分并发地从远程节点接收用于构建过程的后续部分的数据，并且接着基于接收到的数据来完成构建过程。

在一些实施例中，专用faas高速缓存2008、2010可以仅存储与功能相关联的数据对象，藉此加速功能初始化。例如，专用faas高速缓存2008、2010可以仅存储用于容器的初始化数据。诸如通用高速缓存2012之类的其他高速缓存可以存储在功能执行期间由功能生成的数据。

faas管理2006a、2006b可以确定何时以专用faas模式、通用模式或混合faas模式操作服务器2002。例如，faas管理2006a、2006b可以利用历史数据来确定是否要切换到专用faas模式或混合faas模式中。例如，历史数据可指示服务器2002已经多次执行某功能类型。详细来说，faas管理2006a、2006b可以将每一功能分类为功能类型。如果各个功能可以在同一容器中执行，则这些功能可以被认为是相同的功能类型。faas管理2006a、2006b可以将次数与预定数目作比较，并且在该次数大于预定数目时确定专用faas模式或混合faas模式应当被接入。

在一些实施例中，历史数据可以仅包括在一时间窗口(例如前5毫秒)内已经被调用的功能类型。除了驱动关于服务器2002模式的以上决策的历史数据之外，策略、服务水平协议考量和来自编排器的显式指令可以影响用于增加或减少专用faas高速缓存的大小和量的确定。此外，智能nic2004可执行关于从对等机器和/或高速缓存2008、2010、2012取得高速缓存的faas数据的飞行中确定。类似地，此外，faas管理逻辑2006a、2006b可以被实现在增强的faas系统300中以及被实现在各元件中作为cpu308、加速器314、fpga318，并且可执行关于从对等机器和/或高速缓存2008、2010、2012取得高速缓存的faas数据的飞行中确定。以此方式，软件可能不知道faas对象在一组互相联网的服务器2002之中的高速缓存(包括高速缓存2008、2010、2012)中是如何分布的。

如上所提及的，在混合模式中，专用faas高速缓存2008、2010可以与通用高速缓存2012共存。因此在以上示例中，两个高速缓存2008、2010可以专用于faas高速缓存，而高速缓存2012被用作通用高速缓存。因而，在服务器2002上的工作负载的faas部分增加时，来自高速缓存2008、2010、2012的专用faas高速缓存的数目和/或聚合大小可相应地增加。稍后当faas部分降低时，来自高速缓存2008、2010、2012的非常小的专用faas高速缓存继续存在，或者全部高速缓存2008、2010、2012都变为通用高速缓存，其中在高速缓存faas和非faas页、文件等方面没有区别。

在一些实施例中，faas管理2006a、2006b可以从调度器2014接收消息以确定应当接入专用faas模式、通用模式还是混合faas模式。调度器2014可以远离服务器2002，例如在控制节点中。在一些实施例中，服务器2002可包括调度器2014。调度器2014可基于驱动这些决策的历史数据、策略、系统级协议考量以及来自编排器的显式指令来指令faas管理2006a、2006b进入专用faas模式、混合模式或通用模式。

在一些实施例中，调度器2014可进一步指令faas管理2006a、2006b特定容器数据应当被存储在专用faas高速缓存2008、2010中。例如，调度器2014可以确定特定容器要被若干功能利用，并且因此可以指令faas管理2006a、2006b用于该容器的初始化数据要被存储在专用faas高速缓存2008、2010中以供各功能重用。

此外，调度器2014可以部分地基于响应于功能完成执行来指令faas管理2006a、2006b脱离混合faas模式并进入通用模式。例如，调度器2014可以根据功能控制流图、根据所收集的统计数据和内置于调度器2014的工作负载预测规则来确定专用faas高速缓存2008、2010中的初始化数据不会再被已完成执行的功能利用和/或不太可能或不可能处于高需求状态，并因此指令faas管理2006脱离专用faas模式或混合faas模式并进入通用模式或混合faas模式。例如，功能控制图中可基于过去历史被预测的其他功能可以被分派以供在与关联于存储在专用faas高速缓存2008、2010中的初始化数据的容器不同的容器中执行，而对它们的性能或效率不会有显著风险。一旦混合faas模式被脱离，专用faas高速缓存2008、2010可以被重分配并在通用模式中被用作通用高速缓存。

在一些实施例中，调度器2014和/或faas管理2006a、2006b可以标识faas服务器架构2000的负载。如果该负载高于某一阈值，则专用faas模式或混合faas模式可以被接入以有效地平衡资源和等待时间。如果该负载降至低于该阈值，则专用faas或混合faas模式可以被脱离并且接着混合faas模式或通用模式可以被接入。例如，如果负载下降，则专用faas模式可以被切换为混合faas模式，且如果负载进一步下降，则混合faas模式将被切换为通用模式。负载可以通过并发执行的功能、数据访问、通信请求的数目和/或其他测量来测量。在一些实施例中，负载可以由调度器2014和/或faas管理2006a、2006b基于控制流图来预测。例如，调度器2014可以基于控制流图和/或一种类型的功能的激活有多频繁地导致相同类型或另一类型的功能的激活的统计分析来预测若干功能是否会并发操作。

在一些实施例中，服务器2002可以响应于服务器2002将不会处理足够多数目的faas应用的请求的标识来脱离混合faas模式并接入通用模式。例如，在调度器2014可以确定服务器2002不再需要处理大量faas应用请求时，并指令服务器2002退出混合faas模式。

在一些实施例中，服务器2002可以响应于专用faas高速缓存2008、2010中的初始化数据的存活时间期满的标识来脱离混合faas模式并接入通用模式。例如，faas管理2006a、2006b可以维护计数器以确定初始化数据未被使用和/或不被用于构建容器的时间量。faas管理2006a、2006b可以确定该时间量是否超过和/或满足存活时间阈值。如果该时间量超过和/或满足阈值，则faas管理2006a、2006b可以自动脱离混合faas模式并接入通用模式。

以上若干实施例描述了基于某些条件(例如，存活时间期满的标识、负载下降、对过去控制流图的分析、激活序列等)退出专用faas模式和/或混合faas模式。在一些实施例中，代替立即退出混合faas模式，专用faas高速缓存2008、2010中的初始化数据可以被释放并接着由新初始化数据替代。例如，在条件之一被满足时，调度器2014和/或服务器2002可以确定是否要将不同的初始化数据存储在专用faas高速缓存2008、2010中。

例如，调度器2014可以根据控制流图来确定存储在专用faas高速缓存2008、2010中的初始化数据不再相关。即，调度器2014可以确定根据该初始化数据构建的第一容器将不再被使用或将被不频繁地使用。代替立即退出混合faas模式，调度器2014可以参考控制流图和/或历史数据并确定是否将使用第二容器。如果是，则调度器2014可以指令faas管理2006a、2006b擦除用于第一容器的初始化数据，并将用于第二容器的初始化数据存储在专用faas高速缓存2008、2010中。然而，如果调度器2014确定没有其他初始化数据应当被存储在专用faas高速缓存2008、2010中，则可以退出混合faas模式。

在一些实施例中，服务器2002的操作系统可以如上参考服务器2002和/或调度器2014所描述的确定何时接入专用faas模式、混合faas模式、通用模式以及退出专用faas模式、通用模式。在一些实施例中，专用faas高速缓存2008、2010可以是硬件高速缓存。在一些实施例中，专用faas高速缓存2008、2010可以是软件高速缓存，包括但不限于页高速缓存。

包括服务器2002的各实施例可以增加可以在给定时间帧内在服务器2002上执行的功能的数目。此外，用于设立执行环境以运行功能的等待时间(例如时间)(启动时间)和功能消耗的存储器可以是确定可以在服务器2002上执行的功能的数目的因素。如上所述，使供功能执行的资源在存储器(例如温暖容器)中保持准备好可以被用于减少启动时间。为了处理潜在的增加的存储器印记和温暖容器的资源分配，一些实施例可隔绝专用faas高速缓存2008、2010以仅存储用于启动功能和/或用于功能的容器的资源以减少存储器印记和存储器分配。因而，资源争用被减少，且功能的启动时间被加速。在服务器2002不再被用于服务于faas应用或不存在显著负载时，专用faas高速缓存2008、2010可以被自适应地释放。

图20b示出了增强的faas服务器架构2020，其中服务器2022处于如上参考图20a所描述的通用模式。如所例示的，三个高速缓存2028、2030、2032在通用模式中操作。即，通用高速缓存2028、2030、2032可以存储数据对象，但可以不专用于存储与faas有关的对象。通用高速缓存2028、2030、2032存储与faas有关的对象并进一步存储通用数据对象仍然是可能的。

在一些实施例中，图20b中的faas管理逻辑2026a被实现在智能nic2024中。在一些实施例中，逻辑2026a可以替换地作为硬件被实现在服务器架构2000中，例如被实现在处理器中、被实现在基板管理控制器中、被实现在加速器和/或fpga中等。服务器2002可进一步包括faas管理逻辑2026b，其结合faas管理逻辑2026a来操作和/或与其协调地来操作。faas管理2026b可以是服务器2022的os驱动器或智能中间件。faas管理2026a、2026b可以使服务器2022在通用模式、混合模式和专用faas模式之间切换。例如，faas管理2026a、2026b可以从调度器2034接收指令以在通用模式与专用faas模式之间切换。在服务器2022被切换到混合模式时，服务器2022可以类似于服务器2002并且与以上参考图20a所描述的类似地操作。在服务器2022被切换到专用faas模式时，高速缓存2028、2030、2032中的每一者均可以作为专用faas高速缓存来操作。

图20c示出了例示数据对象的数据量的图2040。图2040例示了各个数据对象(x轴)与数据量(y轴)的关系。热容器可以是当前正在执行功能。热容器数据量2042是最大的。温暖容器可以是空闲的，从而当前并未执行功能。温暖容器数据量2044少于热容器数据量2042。初始化数据可以是初始化容器所需的数据，如上文参考图20a和20b所描述的。初始化数据量2046可以是最少的。由此，温暖数据容器量2044与初始化数据量2046的比较例示了可以通过拆除温暖容器2044，将初始化数据存储在一个或多个专用高速缓存中，并从该初始化数据重新初始化容器来达成存储器印记增强。

在一些实施例中，由初始化数据量2046表示的初始化数据可以是对于初始化一个以上的容器而言共同的数据。即，若干容器可以从该初始化数据被初始化。此类共用性可以减少存储器印记，存储器印记的减少通过将该初始化数据存储在专用高速缓存中来代替将数据维持在温暖容器中来达成。例如，容器可以从该初始化数据被初始化。将这些容器中的每一者容器保持为温暖容器会生成若干温暖容器的开销。该开销可至少包括温暖容器数据量2044乘以温暖容器的数目。作为对比，仅需要存在初始化数据的一个副本以初始化那些温暖容器中的每一者。因而，通过不维持温暖容器而是取而代之维持初始化数据，显著降低了存储器开销。

图20d示出了增强的功能资源管理的方法2050，且可由图20a和20b的增强的faas服务器架构2000、2020和/或一个或多个模块实现为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

所例示的处理框2052例如由faas管理逻辑2006a或2006b确定要接入用于服务器的功能模式。该功能模式可以是如上所述的专用faas模式或混合faas模式。服务器可包括多个高速缓存。所例示的处理框2054响应于正被接入的功能模式来利用多个高速缓存中的一个或多个高速缓存作为专用功能即服务高速缓存来存储初始化数据。初始化数据可以被用于发起功能的执行。在一些实施例中，初始化数据可以仅仅是用于发起功能的总数据集的一部分。所例示的处理框2056可以基于高速缓存在一个或多个专用功能即服务高速缓存中的初始化数据来初始化功能。例如，初始化数据可以被用于构建用于执行功能的容器。所例示的处理框2058可以基于降低的对温暖容器的需求、降低的功能激活率、或降低的预计功能激活中的一者或多者的标识来脱离该功能模式。所例示的处理框2058可以释放该一个或多个高速缓存以免于专用于初始化数据，和/或接入通用模式。例如，该一个或多个高速缓存可以被用作通用高速缓存而非被用作功能即服务高速缓存。方法2050可以增强资源利用并减少功能的等待时间，如上所述。

附加注解与示例

示例2000包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：确定接入用于该计算设备的功能模式，其中该计算设备包括多个高速缓存，响应于该功能模式被接入，利用该多个高速缓存中的一个或多个高速缓存作为专用功能即服务高速缓存来存储初始化数据，其中该初始化数据要被用于发起功能的执行，其中该初始化数据仅仅是用于发起功能的执行的总数据集的一部分，其中该初始化数据要被用于构建用于执行功能的容器，基于高速缓存在一个或多个专用功能即服务高速缓存中的初始化数据来初始化功能，基于降低的对温暖容器的需求、降低的功能激活率、或降低的预计功能激活中的一者或多者的标识来脱离该功能模式，响应于该功能模式被脱离，释放该一个或多个高速缓存以免于专用于初始化数据，以及响应于该功能模式被脱离，将该一个或多个高速缓存用作通用硬件高速缓存。

示例2001包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：确定接入用于该计算设备的功能模式，其中该计算设备包括多个高速缓存，响应于该功能模式被接入，利用该多个高速缓存中的一个或多个高速缓存作为专用功能即服务高速缓存来存储初始化数据，其中该初始化数据要被用于发起功能的执行，以及基于高速缓存在一个或多个专用功能即服务高速缓存中的初始化数据来初始化功能。

示例2002包括示例2001的至少一种计算机可读介质，其中该初始化数据仅仅是用于发起功能的总数据集的一部分。

示例2003包括示例2002的至少一种计算机可读介质，其中该初始化数据要被用于构建用于执行功能的容器。

示例2004包括示例2001的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：基于降低的对温暖容器的需求、降低的功能激活率、或降低的预计功能激活中的一者或多者的标识来脱离该功能模式。

示例2005包括示例2004的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：响应于该功能模式被脱离，释放该一个或多个高速缓存以免于专用于初始化数据。

示例2006包括示例2005的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：响应于该功能模式被脱离，将该一个或多个高速缓存用作通用硬件高速缓存。

基于地址空间的qos

在faas环境中，能够对应用、线程、或虚拟机(vm)排定优先级是重要的。根据软件(os/vmm)向硬件指示哪些应用或vm是高/中/低优先级的现有办法是不精确的且资源密集的。

对应用、线程和/或vm排定优先级的现有解决方案的一个示例是基于服务类(clos)线程的接口。虽然基于clos线程的接口可以是方便的、当前被部署的且可以被广泛接受的，但是它遭受至少两个缺点，即(1)缺乏精度——无法指定在平台中应当如何处理每一高速缓存行，以及(2)在每一次上下文交换时存在交换clos的开销。增强的faas解决方案的一些示例性实施例可以提供更精确的且相对于用于指示哪些应用或vm是高/中/低优先级的必要资源而言成本更低的技术方案。

增强的faas解决方案的示例性实施例提供对诸如末级高速缓存(llc)和存储器带宽等共享资源如何被应用、vm和容器使用的可视性和控制(例如，rdt或平台服务质量)。可以构建此类技术的延伸以实现基于地址的qos，其中(1)特定的地址空间范围被加标签为具有服务类(clos)，或者(2)个体页可以通过增加每页属性来管理。基于地址空间的qos可以通过按照存储器类型范围寄存器(mtrr)的样式来指定地址范围或类似保护密钥的办法来开发，在类似保护密钥的办法中通过以控制寄存器(cr)或模型专用寄存器(msr)为基础并限制控制寄存器(cr)或模型专用寄存器(msr)来指定范围。在此类情形中，现有的范围寄存器可以被重用，或者新的范围寄存器被引入，只要每一范围寄存器与clos相关联以实现加标签。在一些实施例中，其他机制可以被用于加标签和过滤，例如，软件可以填充范围标签表，该范围标签表通过处理器、存储器控制器、或各种具备dma能力的设备的地址转换服务(ats)中的硬件机制通过高速缓存被加速。

clos可以是软件指派的标签，线程/应用/vm/容器可以被分组到该标签中。该标签可以在软件线程或vcpu开始在硬件逻辑线程(例如，核上的同时多线程(smt)线程)上运行的任何时间被交换进入msr。软件可以灵活地将零个或多个线程指派到clos中，接着可以针对每一clos来设置(同样地由os/vmm设置以满足优先级需要)诸如llc处的高速缓存容量或存储器带宽之类的平台资源。此类指派可以分别经由图4和5中的faas系统400或500中的任何一者来执行。

在示例性实现中，每一页表条目可以被扩展为具有clos标签。在cpu在转换后备缓冲器(tlb)未命中期间遍历页表时，clos属性可以被检取并被使用，并且被高速缓存在tlb中。这意味着对于所访问的每一页上的每一行，clos可以被提供以实现比先前可能的更精细粒度的qos加标签。

虽然基于线程的加标签在如今可以被部署并且可以在各faas线程之间对faas线程排定优先级方面发挥作用，但是基于范围或地址的加标签的概念使得faas线程内的数据也能够被排定优先级，这可以更好地符合faas更精细粒度的特质。基于地址的加标签在诸如iot、工业自动化、移动控制和实时计算等其他用途中还可能存在技术优势，其中关键存储器范围可以被优先化或者“伪锁定”在高速缓存中，藉此实现比先前可用的更精细粒度的控制。

在开发过程期间，上述办法可以被集成到工具链中，并且关键数据可以在链接器脚本的特殊部分中被加标签，从而实现基于地址空间的qos以确保优先级排定。类似地，已知流传输数据(其可能污染高速缓存)可以被去优先级。因而，对于专门用途，基于地址空间的qos可以提供现有基于线程的加标签技术之上的附加益处。

在一个实施例中，与结合图8a描述的相似或相同的电子处理系统，可包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，以执行操作来对软件或软件线程排定优先级。在一些实施例中，该逻辑可位于各种组件中或与各种组件共处一地，这些组件包括(例如，在同一管芯上的)处理器、存储器等。

在另一实施例中，与结合图8b所描述的相似或相同的半导体封装装置，可包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地在可配置逻辑和固定功能硬件逻辑中的一者或多者中实现。耦合至该一个或多个衬底的逻辑可以被配置成执行操作以对软件或软件线程排定优先级。在一些实施例中，耦合至该一个或多个衬底的逻辑可包括位于该一个或多个衬底内的晶体管沟道区。

现在转向图21a，该附图例示了根据一个实施例的对软件线程排定优先级的方法2150。方法2150在框2152中包括确定软件线程是否正在硬件逻辑线程上运行的操作。在框2154，在软件线程正在硬件逻辑线程(例如处理器核)上运行时，可以将标签交换进入寄存器。最后，在框2156，可以针对每一标签设置一个或多个高速缓存容量和存储器带宽。根据示例性实施例，可以通过操作系统和/或虚拟机管理器(vmm)来设置高速缓存容量或存储器带宽中的一者或多者。

此外，根据示例性实施例，可以基于运行时性能指示符、有问题的存储器区划或区域、和/或基于访问模式在运行时将数据和应用动态地移动到不同的性能类中。

方法2150的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法2150的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法2150可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法2150的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

页级qos

cpu的性能很大程度地依赖于低等待时间、高带宽存储器访问。现代cpu架构取决于多级高速缓存来减少等待时间和外部存储器解决方案(诸如ddr)的带宽约束。高速缓存技术可以被用于改进cpu的整体性能，并且诸如高速缓存qos(高速缓存分配技术cat)和存储器带宽分配(mba)之类的特征(两者都是现有特征)提供了确保针对多核处理器内的特定核的更强性能的方式。cat和mba在许多环境中提供益处，但是依赖于线程级加标签。这意味着在标签被施加(用于资源控制的服务类clos或用于监视的资源监视idrmid)之后，与线程相关联的后续活动受到控制和/或监视。然而，当前没有方法来以对线程访问的数据地址敏感的和/或与线程访问的数据地址相对应的方式来控制线程的数据放置。在其中对特定地址的最重要的高速缓存未命中可能对性能具有显著影响且具有执行抖动的实时或重要线程中，这可能导致线程难以微调和优化以使它们最关键的数据保持在高速缓存中。在实时环境中，在构想最坏情形执行时间时这些高速缓存未命中被采纳，从而显著影响编程人员保证确定性的实时工作负载完成时间的能力。

例如，如果第一核(核a)具有规律地每100μs消耗一次数据a(<1kb)但进而还执行消耗整个l3高速缓存的流处理操作的工作负载，则数据a可能被迫从l1、l2和l3高速缓存以及二级tlb(stlb)中的tl条目被驱逐。通过随后以100μs的常规心率再次访问数据a的这一模式，可能常常存在不可预测的增加的等待时间，该不可预测的增加的等待时间通过从ddr取得存储器(包括转换数据a的虚拟地址所需的页遍历)而施加(其中，转换稍后被存储在tlb/stlb结构中，但是在之后被流传输工作负载阶段的大工作集强制移出)。在实时环境中，这一增加的等待时间会进一步减少可用的执行周期，从而只剩余低于70％的总可用性能，因为周期预算必须被填充以计及最坏情形的高速缓存和tlb行为。在对于10μs心率具有在量级方面具有更紧界限的一些情形中，有效性能可能<50％。作为另一示例，通过对执行进行时间划片在核上的混合工作负载还可能引入高速缓存和stlb压力。

增强的faas和实时解决方案的示例性实施例可允许高速缓存分层结构通过阻止不必要的驱逐和昂贵的页表遍历来改进数据块在高速缓存中的驻留。

另外，根据示例性实施例，clos选择可以被附加到页属性，并且向高速缓存分层结构提供改进用于关键路径执行的高速缓存行驻留期的方法。由操作系统分配到页表中的每一页可以定义为该页的所选择的clos。在进行存储器加载/存储并且数据必须被带入高速缓存中时，页属性可以指示clos可以使用的高速缓存块，具体地它被允许驱逐以腾出空间的方式。类似地，对于stlb，在页转移被读取时，可能具有被分配给由页属性定义的clos的stlb的特定位置，从而改进tlb条目的驻留期。换言之，clos标签可以被用于将重要数据(在来自以上两段的示例中是数据a)分配到l1/l2/l3等级别的高速缓存和/或stlb的受保护分区中。该数据在受保护分区中的存在消除了它会被驱逐的可能性，这意味着该数据在被需要时是存在的，从而减少了需要从存储器取得该数据而引发的执行抖动。

页级qos启用单独地对待每一数据块的能力(该术语也可指代字节、高速缓存行、或页级的管理，但出于实现的效率，页级可以是共用办法)。指令可以被映射到具有特定属性(诸如clos标签)的页，并且在关键路径执行的情形中，关键路径指令可具有带有特定qos要求的单独的页。类似地，对于数据，具有较低访问频率的关键路径项可具有阻止停止存储器访问的特定qos要求。将期望的qos标签(例如clos)纳入页属性可实现与高速缓存控制特征(诸如各个高速缓存级别处的cat)以及与stlb分区特征的更好的集成，从而实现确定性的驻留期和更简单的建模以保证最坏情形执行时间。

上述办法可以与核级qos的相关解决方案(传统rdt)不同，在传统rdt中clos通过控制存在于核内的所有下游构造的寄存器来定义。由于安全风险，clos通常通过对用户空间应用不可用的特权寄存器来控制。通过这一线程加标签实现，在用于所有存储器操作的执行期间的任何给定时间，仅一个clos可以被任务使用。核级qos可能是更有问题的，因为它假定任务内的所有数据被相同地对待(且在如smt的情形中那样每一核上存在多个线程的情况下核级特征更难以管理)。因此，在没有诸如“伪锁定”等复杂的专用流的情况下，在“伪锁定”中clos被切换并且在使用之前数据被先验地“打底”到高速缓存中，任务无法控制什么项将在l2或stlb高速缓存中具有特定驻留期要求。相应地，在没有此类复杂的设置操作和/或步骤的情况下，流处理操作可以驱逐高速缓存中的所有关键路径项。此外，伪锁定解决方案虽然有时候是有效的，但是也可能是“脆弱的”，因为它们可能受到不可预见的微架构行为的影响，这使得构建围绕高速缓存行为的保证变的相当困难。在每一核上具有许多合并任务的执行环境也可能提出问题。在该场景中，针对每一任务拆分出可调大小的量的高速缓存而不影响性能的能力可能是困难的。

页级qos可以提供通过将clos定义在一个示例实施例中以页级添加到页表中的条目来改进运行时服务质量的方式。可以通过以下场景来展示预期使用。例如，在应用准备好执行时，操作系统可以分配页以将该应用的所有二进制区段放置到存储器中。每一二进制段可以被加标签有通过某种方式对于操作系统可见的clos，并且可以被放置到由该clos确定且有该clos标签的所分配的页中。这可允许应用的不同段具有较高或较低的优先级以改进整体服务质量，但是更重要的是对于重要页中的关键数据片段，它们具有更高的可能性可以被保持在高速缓存/tlb中，并且更简单的接口被提供(通过页级接口来将这些数据区域加载到高速缓存/tlb中)。

在页被分配时，每一页条目可以被添加到页表，伴随有定义用于该页所表示的存储器的clos的附加位。在运行时，页条目可以由cpu检取以提供虚拟到物理的地址转换，此时可以标识要访问的存储器的clos。由于clos可以定义高速缓存分层结构如何被分区，因此存储器接着可以被加载到用于该clos的分区所定义的共享资源区域(诸如高速缓存级的stlb)中。在驱逐的情形中，仅请求访问高速缓存的特定分区的新存储器请求可以从高速缓存分区中驱逐项。这意味着单独分区中的重要数据可以受到保护以免于驱逐。这可以极大地改进对于被保留的分区而言项在高速缓存中的驻留期，从而提供另一种(及可能的更稳健)方式的伪锁定。在运行时期间存储器应用的情形中，可以向将存储器分配到堆上的操作系统调用附加地提供为要被创建的新页表条目选择的clos。

现在转向图21b和图21c，这两个附图示出了任务与页表中的clos之间的交互以在增强的faas架构中提供页级qos。页级qos可以通过将程序的各个段划分到不同的clos中从而允许某些段或段内的某些数据要在高速缓存/tlb中被特别地优先或保护来提供益处。在图21b中，应用2160可以具有三个单独的任务(例如，任务0、任务1、任务2)，每一任务具有特定的实时确定性要求。这些任务中的每一者具有其自身的代码和数据段(.text和.bss)以允许执行期间的特定高速缓存分区同时仍然共享全局的进程级上下文(例如，如在多线程应用的情形中那样)。数据2161和代码2162与任务0有关，数据2163和代码2164与任务1有关，而数据2165和代码2166与任务2有关。每一任务的代码和数据被定标到高速缓存的特定分区中，从而对执行时间提供更多确定性并允许更紧的最坏情形执行时间计算。根据图21b的示例性实施例，.bss和.text段可以共享相同的服务类，但是这些段可以基于存储器尺寸约束和所要求的确定性程度被进一步划分。

现在转向图21c，在运行时，任务0可请求来自作为cpu核0l2和l3高速缓存的分区的存储器分配器clos3的堆数据2170。任务1也请求来自作为cpu核1l2和l3高速缓存的分区的clos4的堆数据2171。对于cpu核0，可以如下且如图21c中所示地对传感器数据执行示例性紧循环：

1)传感器数据通过pci-edma被置于l3/llc中。例如，英特尔ddio特征将存储器中存储的某些数据高速缓存在l3/llc高速缓存的专用区域中。

2)任务0消耗输入传感器数据，将其流传输到clos3l2高速缓存分区中同时也更新bss_clos_0ds中的数据。

3)任务0通过bss_clos_2内的数据产生用于任务2的输出，并且循环回到步骤1。

对于cpu核1，任务1可以基于与任务0或任务2没有数据相关的外部中断而与任务0异步执行。由于实时确定性，任务1在高速缓存中的驻留期可能是关键的。

对于cpu核1，任务2可以如下与任务0的输出等时地对齐进入bss_clos_2：

1)通过bss_clos_2读取来自任务0的输出。

2)在cpu核1l2和l3高速缓存中创建具有clos4的写输出数据。

3)pci-e上的nic读取从l3读取输出数据。

现在转向图21d，这一附图例示了与图21c中类似的场景，除了其中线程级qos被用于定义clos。首先，鉴于cpu核02180，由于仅任务0正在cpu核02180上运行，而没有专门的基于软件的技术和被专门微调来支持它的高速缓存分层结构，因此可能无法对高速缓存进行分区以增加text_clos_0或bss_clos_0在传感器数据中流传输时的驻留期。这可能迫使高速缓存中的不期望的驱逐，并且在发生附加高速缓存未命中时减低整体确定性。接着考虑cpu核12181，在任务1与任务2之间仍然可以存在分区，但是对堆输出数据的流传输的写可以与clos2组合。这可能导致对bss_clos_2和text_clos_2的不期望的驱逐，从而进一步降低传感器(或在此情形中是分组)数据被命令发送与nic实际向外发送之间的定时的确定性。换言之，由于高速缓存的共享，在应用发出要发送的命令的时间与数据实际在线缆上被发送的时间之间存在不确定的等待时间。该等待时间是由于pcie设备需要从存储器读取数据且数据可能被高速缓存或可能未被高速缓存的事实引起的。最终，这一高速缓存的不确定性导致执行时间方面的不确定和抖动。

考虑最大的确定性存储器块l3高速缓存2182，粒度被减小，以使得堆输入和输出数据可导致对关键代码和数据的进一步驱逐。虽然l2驱逐向l3高速缓存2182增加了不期望的等待时间，但是与管芯存储器块相比需要从外部存储器取得数据可能显著地增加更多的等待时间和抖动。

通过实现页级qos，可以基于数据/指令在高速缓存中的驻留期来开发更具确定性的模型，从而允许更紧的实时执行约束和更高的核利用。对于重要性很高的关键faas工作负载而言，这是非常重要的改进。

附加注解与示例

示例2101包括一种方法，其包括：确定软件线程是否正在硬件逻辑线程上运行，在软件线程正在硬件逻辑线程上运行时将标签交换进入寄存器，以及为每一标签设置高速缓存容量和存储器带宽中的至少一者。

示例2102包括示例2101的方法，其中该标签是来自页表的服务类(clos)标签。

示例2103包括示例2101的方法，其中高速缓存容量和存储器带宽中的至少一者由操作系统和虚拟机管理器中的一者来设置。

独立于合并并发线程数目来确保可预测faas吞吐量和公平性

根据示例性实施例，可以在faas环境中提供确保确定性和公平性的硬件或软件解决方案。此类解决方案可以被实现以确保计费的一致性、准确性和公平性。faas资源的管理和监视被设计为是一致的以确保对资源使用的准确计费。

评估faas资源使用方面的公平性是必要的，因为租户在faas资源被使用时进行支付，并且在对同一工作负载重复调用的情况下，另一租户的线程活动引起的一个租户的线程变慢可能导致运行时的不公平性或变动(且因而导致计费的变动)。相应地，cpu调度量子段可以被调整以确保公平性；计费统计数据可以被用于测量被给予的cpu时间和总体公平性；并且带外(oob)遥测也可以在监视应用以理解当前正被实现的公平性程度方面起作用。然而，控制是重要的，如下所述。

根据示例性实施例，存在至少两种用于确保确定性和公平性的办法：1)划分共享资源以确保每一个功能具有对共享资源的均等访问，或者2)实现硬件或软件性能管理控制器，其执行以下操作：

a.监视和控制

b.动态功能资源控制和迁移

图22例示了用于在faas环境中提供确定性和准确性的示例性架构。在图22中，计算设备(例如性能控制器2210)可以执行紧接着的上一段中的操作“a”和“b”。计算设备2210还可提供基于历史的资源调度，将数据重定向到恰适的核以进行调用，最大化数据共享并最小化数据移动，根据服务水平协议来捆绑功能。计算设备2210的上述操作也可以经由软件来实现。

为了确保确定性和公平性，计算设备2210或软件可以拆分l2高速缓存，以使得其由不同的核2220、2230来处置，尤其在l2被填充的情况下。

根据示例性实施例，计算设备2210可以将代码与数据拆开。附加地，功能可以被四处移动以确保它们被很好地均衡，例如，如果一个资源后端繁重，则可以基于调度器在不同核上混合和匹配各功能。附加地，计算设备2210可以动态地重分配临时资源。

运行时2240可以在或可以不在图22的架构中实现。当在图22的架构中被实现时，功能可以调用运行时以从基础设施获得服务和指令，以避免操作系统专用调用。

用于faas的增加的计费准确性

用于计费的基于软件的时间采样办法对于faas而言可能是不够的，因为它会遭受偏斜和高开销。如果计费是基于毫秒的，则需要使得计算资源使用可以按微秒来测量的粒度。

随着数据中心中的工作负载时间标尺减小，精细粒度的监视和计费变得越来越重要。faas被设计成允许消费者计费降至毫秒级，这要求运营商将可验证的计费精度维持在微秒级以确保准确性。用于以最小开销支持此类计费的硬件技术因而变得有必要，并且下文描述了若干技术。

根据示例性实施例，提供了用于计费管理和监视的硬件办法，其具有低开销并实现基础设施对计费统计数据的周期性按需检取。该示例性实施例可以从faas功能的上下文交换路径中移除时间核算的开销，从而改善开销和成本。

将对vm进行计费作为一个示例，传统地，vm可以通过基于web的控制台或移动应用来管理，并且可以由管理员按需地旋转加速或旋转减速。然而，通常计费是在逐分钟的基础上来管理的。这一粗粒度的计费在其基础设施中是低成本的，且由消费者进行管理和验证是直接的。即，对于此类系统的要求是低的(例如，出于这一目的，基本的跟踪和时间同步的基础设施以及现有协议(诸如ntp)是足够的)。

在faas所要求的精细粒度计费中，诸如上文在vm的情形中描述的粗粒度计费之类的传统技术可能是不够的。对os时间进行基于软件的时间采样的api会遭受偏斜，并且高速率的功能调用/终止可能导致用于收集时间值、计算时间戳之间的差等的高开销。这可能导致：(1)增加的运营商成本，以及(2)消费者描述以供运行时的内容与运营商报告的内容之间的可能的失配。随着时间累积的不精确和不准确进一步加剧这些问题。

与软件解决方案相反，硬件办法可涉及非常低的开销，并且实现基础设施对计费统计数据的周期性按需检取。若干加标签技术或解决方案用于硬件辅助的faas计费是可能的，以唯一地标识功能或特定线程及其在系统中的对应活动，包括但不限于：

1)资源监视id(rmid)技术——在os/vmm交换rmid时，可以使用rmid资源跟踪标签来跟踪faas功能。每一功能(或每一租户)可以被指派rmid，并且新cpu硬件可以被构建或启用以跟踪cpu上的rmid时间(以精细粒度的时间为基础或者以cpu参考时钟周期为单位)。接着可以经由新msr或mmio块(其报告rmid到时间使用)来报告新的每一rmid事件代码或可以报告资源使用。

2)进程地址空间id(pasid)技术——根据示例性实施例，pasid是作为pcie第三代规范附录的一部分引入的20b标签。pasid可以被指派到每一核，并且被用于其他特征，如可缩放i/o虚拟化(siov)。由于可以构建或启用新的硬件来跟踪每一pasid使用的cpu时间，因此这可以是跟踪唯一功能计算时间使用的非常高效的方式(通过这一技术使得与上文的基于mmio或基于msr类似的实现选项可用)。增加计数器跟踪系统来跟踪每一pasid消耗的cpu周期将是实现这一办法的重要部分。

3)逻辑处理器id(lpid)技术或每线程或每核——逻辑处理器id、线程或核可以类似于pasid和rmid来使用，并且可以添加类似的每实例计数器来跟踪cpu利用。这将可能要求os/vmm在每一次上下文交换时读取这些计数器，或者将需要硬件来代表软件聚合这些结果。

4)基于控制寄存器cr3的技术——如果基础页表地址形成进程的基础，则在每一唯一控制寄存器cr3的基础上在硬件计数器中跟踪cpu时间。可以跟踪每一cr3唯一值消耗的时间或周期(对于最活跃的cr3以降低成本)以便跟踪cpu利用。

5)基于vmvcpu的技术——为每一vm虚拟cpuid指派硬件计数器(可以与vt-x架构相关联)，此类计数器可以跟踪每一vcpu的cpu利用(且在实际中还可能需要上文描述的其他技术来跟踪针对非虚拟化情形的利用)。

6)基于远程原子(rao)的技术——rao可以在非核处构建可被用于跟踪cpu时间的逻辑，例如，在每一次通过硬件(或显式地通过软件)自动地进行上下文交换时对于给定的进程id/pasid/rmid等，已发布的rao指令可以被用于将“递增x周期”发送到跟踪硬件。从未来各代服务器硬件开始，这对于软件中的rao变量是可能的。非核可以反映不在核中但是可以被紧密连接到核以达成高性能的微处理器的功能。非核可以提供各种能力，例如高速缓存、存储器控制器访问、i/o设备访问(经由例如pcie)等，并且通常可提供用于将所有功能绑定在一起的高性能互连。

6)基于远程原子(rao)的技术——rao可以在非核处构建可被用于跟踪cpu时间的逻辑，例如，在每一次通过硬件(或显式地通过软件)自动地进行上下文交换时对于给定的进程id/pasid/rmid等，已发布的rao指令可以被用于将“递增x周期”发送到跟踪硬件。从sapphirerapids(服务器)开始，这对于软件中的rao变量是可能的。非核可以反映不在核中但是可以被紧密连接到核以达成高性能的微处理器的功能。

在以上加标签方案中的一者或多者中，还可以要求按需对计数器进行采样/读取且可任选地按需清除计数器的机制(例如，用于为新租户重指派和回收pasid或rmid)。根据示例性实施例，上述标签可以由os或其他硬件来指派。

在一个实施例中，与结合图8a描述的相似或相同的电子处理系统，可包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，以执行操作来计算资源使用。在一些实施例中，该逻辑可位于各种组件中或与各种组件共处一地，这些组件包括(例如，在同一管芯上的)处理器、存储器等。

在另一实施例中，与结合图8b所描述的相似或相同的半导体封装装置，可包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地在可配置逻辑和固定功能硬件逻辑中的一者或多者中实现。耦合至该一个或多个衬底的逻辑可以被配置成执行操作来计算资源使用。在一些实施例中，耦合至该一个或多个衬底的逻辑可包括位于该一个或多个衬底内的晶体管沟道区。

现在转向图23，这一附图例示了根据示例性实施例的一种出于计费目的来计算资源使用的方法2300。方法2300在框2310包括跟踪cpu上的资源监视标识符(rmid)时间的操作。在框2320中，可报告rmid时间。在框2330中，计数器清除模块可以被配置成按需保存和/或清除计数器并且重指派rmid。

附加注解与示例

示例2301包括一种装置，其包括：中央处理单元、资源监视硬件模块、以及代码报告硬件模块，该资源监视硬件模块被配置成使用资源监视标识符(rmid)来在功率管理单元中进行划分并且跟踪cpu上的资源监视标识符(rmid)时间，该代码报告硬件模块被配置成报告rmid时间。

示例2302包括示例2301的装置，其中要对于每一rmid来指派用于对硬件事件进行计数的硬件计数器。

示例2303包括示例2301的装置，进一步包括计数器清除模块，该计数器清除模块要被配置成按需清除计数器并重指派rmid。

智能遥测引导的调度的示例

常规调度器/编排器基于可用性来分发各个功能，而没有关于功能如何表现的反馈。增强的faas解决方案(诸如结合图5描述的增强的faas解决方案)的一些实施例可以收集关于功能被执行时的行为(例如，功能花费了如此多的时间、使用了如此多的高速缓存等)的信息，并且基于所收集的信息起来作出更好的调度/编排决策。例如，各个硬件架构可以提供多个计数器，其可以提供与功能行为有关的有用信息。一些实施例可以收集与功能有关的信息(例如，而非每一数据点)的统计数据。例如，所收集的信息的数据库可以被调度器/编排器维持和使用以用于将来路由决策。有利的是，一些实施例可以作出更好的分发决策，提供更好的资源利用等。

现在转向图24a，分布式计算环境2440的实施例可包括与一个或多个执行环境(例如，平台、服务器等)2442通信耦合的服务器2441。在一些实施例中，服务器2441是增强的faas系统。服务器2441可包括用于将功能调度和路由到执行环境2442的编排器2443。执行环境2442可以与数据收集模块2444通信耦合，数据收集模块2444可以被配置成收集与功能的执行有关的信息。数据收集模块2444可以通信耦合至数据存储2445，数据存储2445可以存储所收集的信息(例如，单独地、以汇总的形式、与所收集的信息有关的统计数据、在某种结构化的数据库中等)。编排器2443可以通信耦合至数据存储2445以利用所存储的数据来作出关于如何调度和路由功能的决策。在一些实施例中，可以仅在达到某一使用水平的功能上实现编排和/或数据收集(例如，1000实例化以下的功能不基于所收集的数据来编排，而超过1000实例化的功能使数据被收集并基于所收集的数据来编排)。在一些实施例中，在功能成为公知之后(例如，在功能被执行超过预定义的阈值次数之后)收集可以被停止。

详细来说，编排器2443将功能路由和调度到将运行这些功能的系统，诸如服务器2441。编排器2443可以定位具有空闲周期的系统和/或子系统，并将功能执行路由到这些系统和/或子系统。编排器2443的一些实施例可以提供智能调度器，其使用来自功能的先前运行的遥测信息来实现更高效且更经济的执行。在一些实施例中，编排器2443可包括标识低效性(例如，高功耗、长于预期的等待时间等)以及用于解决这些低效性的增强的ai和/或mi。ai和/或mi可以调整功能在服务器2441上的调度和/或分发，并且确定这些调整是否有效(例如，执行一批功能，并确定是否阻止或减少了低效性)。如果是，则编排器2443可以基于这些调整来继续调度和/或分发其他功能。否则，编排器2443可以再次使用ai和/或mi来尝试不同的调整集以克服低效性。遥测信息可以以各种方式来收集，包括对主机系统上的事件的无缝统计采样以及对代码的静态或动态检测以收集功能的静态和动态简档信息。可以被收集的事件信息的非限制性示例包括微架构事件信息，诸如数据/指令高速缓存未命中、分支误预测、热计数器、ipt、rdt等(例如，(cpu上的)带内、或通过csme的带外)。可以被收集的其他信息的非限制性示例包括功能的动态调用图、基本块计数、api调用等。所收集的信息可以被组织为对应于功能的静态/动态简档信息。

编排器2443的智能遥测引导的调度器的实施例可以使用所收集的关于功能的信息(例如，或信息的汇总)来动态地将功能路由到良好地适用于或最佳地适用于功能执行的系统或系统池/子系统(例如，可用资源、足够的计算、存储器、存储等)。通过对所收集的关于功能的遥测和简档信息的适当预处理，智能调度器可以能够快速地评估在其控制下的系统的资源可用性。例如，调度器可以标识具有用于调度功能所需的足够量的高速缓存的系统或系统池。所收集的信息的粒度可取决于实现而变动，但是智能调度器的各实施例可以解决功能的要求向量与可用系统的要求向量进行匹配的问题。调度器可以被认为是智能的，因为越多功能执行，调度器可具有关于它们的预测行为的越准确的信息。

在遥测引导调度的一个实例中，编排器2443的智能调度器的实施例可以预测失败并且防止失败。例如，编排器2443的智能调度器的一些实施例可以在崩溃点记录服务器2441的状态，包括什么功能正在运行、资源利用向量(例如包括功率简档等)等。智能调度器可以潜在地看到许多失败案例，并且创建深度神经网络dnn以用于快速匹配系统状态(例如，以预测潜在失败)。

在一些实施例中，编译器可以使用简档引导的优化(pgo)或反馈指导的优化(fdo)以实现提升的编译性能。这可以被认为是人工智能的方面。在事件触发时，许多节点可用于执行功能。各个节点可具有不同的强项/能力，并且关于功能在其中被执行的位置可存在显著或完全的灵活性。编排器2443接收功能并决定如何路由它以被执行。在一些实施例中，在功能被执行时，可以由编排器2443收集关于功能行为的信息(例如，高速缓存未命中、执行的定时等)。一些实施例可以使用许多计数器来收集程序信息和/或功能可以被检测以收集数据(例如，和/或计时器可以被用于收集信息)。检测还可导致代码修改以加速代码(例如，矩阵乘法被标识，从而下一次指示代码利用特定服务器上的硬件)。所收集的数据可以形成功能的简档，编译器可以利用该简档以用于在何处执行功能的简档引导的优化。

编排器2443的一些实施例还可包括改变关于在功能在将来被分发时(例如，加速功能，包括诸如asic、gpu、fpga等的硬件实现)被投入的资源的人工智能决策能力以实现即时(jit)适配。所收集的数据可以被存储到诸如数据存储2445之类的数据库或数据存储中，并被采样以标识执行中的错误。基于这些错误，编排器2443的一些实施例可以标识理想的资源分配和服务器(例如，如果简档指示功能使用大高速缓存，则编排器2443可以将功能路由到具有大高速缓存分配的服务器以避免错误)。编排器2443的一些实施例可利用所生成的简档来提供简档引导的优化，并标识可能的结果以优化对资源的选择。例如，编排器2443的一些实施例可以分析各功能并且使高速缓存使用最大化(例如，将视频流传输到不同用户的两个功能可以被推送到同一服务器)。

现在转向图24b，提供功能即服务的方法2430的实施例可包括：在框2431收集与所执行的功能有关的与行为有关的信息，以及在框2432基于所收集的与行为有关的信息来作出后续功能管理决策。方法2430的一些实施例可进一步包括在框2433确定关于所收集的与行为有关的信息的统计数据，以及在框2434基于所确定的统计数据来作出后续功能管理决策。例如，在框2435，功能管理决策可包括调度决策和编排决策中的一者或多者。

方法2430的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法2430的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法2430可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法2430可在结合下文示例2411至2413来描述的计算机可读介质上被实现。方法2430的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、fpga比特流、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例2400包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：收集与所执行的功能有关的与行为有关的信息，其中该与行为有关的信息包括一个或多个带内信息和带外信息，以及基于所收集的与行为有关的信息来作出后续即时功能管理决策。

示例2401包括一种电子处理系统，其包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，以收集与由该处理器执行的功能有关的与行为有关的信息，以及基于所收集的与行为有关的信息来作出后续功能管理决策。

示例2402包括示例2401的系统，其中该逻辑进一步用于确定关于所收集的与行为有关的信息的统计数据，以及基于所确定的统计数据来作出后续功能管理决策。

示例2403包括示例2401至2402中的任一者的系统，其中功能管理决策包括调度决策和编排决策中的一者或多者。

示例2404包括一种半导体封装装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地实现在可配置逻辑和固定功能硬件逻辑中的一者或多者中，耦合至该一个或多个衬底的逻辑用于收集与所执行的功能有关的与行为有关的信息，以及基于所收集的与行为有关的信息来作出后续功能管理决策。

示例2405包括示例2404的装置，其中该逻辑进一步用于确定关于所收集的与行为有关的信息的统计数据，以及基于所确定的统计数据来作出后续功能管理决策。

示例2406包括示例2404至2405中的任一者的装置，其中功能管理决策包括调度决策和编排决策中的一者或多者。

示例2407包括示例2404至2406中任一者的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例2408包括一种提供功能即服务的方法，其包括：收集与所执行的功能有关的与行为有关的信息，以及基于所收集的与行为有关的信息来作出后续功能管理决策。

示例2409包括示例2408的方法，进一步包括确定关于所收集的与行为有关的信息的统计数据，以及基于所确定的统计数据来作出后续功能管理决策。

示例2410包括示例2408至2409中的任一者的方法，其中功能管理决策包括调度决策和编排决策中的一者或多者。

示例2411包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：收集与所执行的功能有关的与行为有关的信息，以及基于所收集的与行为有关的信息来作出后续功能管理决策。

示例2412包括示例2411的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定关于所收集的与行为有关的信息的统计数据，以及基于所确定的统计数据来作出后续功能管理决策。

示例2413包括示例2411至2412中的任一者的至少一种计算机可读存储介质，其中功能管理决策包括调度决策和编排决策中的一者或多者。

智能功能调度以最大化存储重用的示例

增强的faas系统(诸如上文结合图4的描述所描述的增强的faas系统)可以有利地提供智能功能调度以最大化存储器重用。存储器是有限资源，并且功能和数据占据存储器中的空间。一些实施例可以将相同语言栈的功能实例路由到相同的底层系统/机器/存储器。jit创建的代码也可以被重复，并且在一些实施例中，重复的jit代码的实例可以被路由到相同的底层系统/机器/存储器。一些实施例可以优选地将利用相同语言(例如，java、python等)的功能路由到相同的机器和/或物理节点。一些实施例可以附加地或替换地将共享数据路由到相同的系统/机器/存储器(例如，地图数据)。

增强的faas系统(诸如下文图25a中的faas系统2540)的执行环境可以加载共用代码库(例如，动态链接库(dll))和/或共用数据(例如，数据集、数据库、地图数据等)来执行功能的执行。此类共享库可以是昂贵的和/或具有大量数据。增强的faas系统2540的一些实施例可以有利地将相同语言的功能路由到相同的机器以获益于共享库。在一些实施例中，共享库可以类似于共享功能的不同实例来被对待。在一些系统各种，例如，相同功能的已编译代码可以是相似的。增强的faas系统2540的一些实施例还可利用共享数据(例如，两个功能可以都访问相同的地图数据，并且一些实施例可以将两个功能路由到同一机器)和资源的优势。

增强的faas系统2540的一些实施例可包括存储器重用技术，其通过仅使用存储器区域中具有恰好相同的位串的物理存储器(例如高速缓存行)的一个副本来实现较大的存储器带宽和较短的存储器访问等待时间。例如，当数千个相异的高速缓存行全都具有相同的值(例如，在所有位都是0或1或0和1的任何排列时)，物理存储器将仅存储重复区域的一个副本。存储器重用技术可以利用与散列相组合的额外的间接性来重用同一存储器位置。然而，当这些区域中的一者改变时，可以为新值创建新区域，并且如果排列已经存在，则间接性机制会将经修改的区域映射到已经存在的存储的值。存储器重用技术的益处在于使全部位都为0或1的共用模式避免数据重复。增强的faas系统2540的一些实施例可以增加获益于用于功能代码以及数据的存储器重用技术的可能性。

附加地，faas平台中的各个功能常常在托管运行时(例如，javascript、python、java、c#等)上。这些平台中的每一者具有多个共享库，诸如被动态加载和链接的dll。在多个应用使用相同dll时，os通常使一个dll保持在主存储器中，且该dll被共享用于加载该dll的所有应用。附加地，这些托管运行时中的大部分托管运行时具有为其高级语言动态地生成代码的jit编译器。增强的faas系统2540的一些实施例可以有利地提供调度器/编排器(例如图24b中示出的编排器2443)来将相同语言的功能、或与先前被路由的功能相似或相同的其他功能路由到相同的系统或相同的系统池。此外，使用相同数据(例如，相同的地图、流传输相同的视频等)的功能可以被路由到相同的系统或相同的系统池。有利的是，增强的faas系统2540的一些实施例可以增加这些不同功能将具有大量代码/数据(例如，就静态代码、dll、jit生成的代码、jit生成的数据等方面而言)重复的可能性。配备有存储器重用技术的系统可进一步获益于一些实施例，因为存储器重用技术实际上可以在非常精细的级别(包括高速缓存级别)只使用每一重复代码的一个实例。有利的是，一些实施例可以降低存储器对带宽的压力，并且功能/应用可具有更多用于数据的存储器以及对它们使用的代码的更快速的访问。

在一些实施例中，增强的faas系统2540的系统软件可以被配置成将具有高度存储器重用机会的代码和数据结构在高速缓存行边界处对齐。另外，用0来填充一些数据结构的尾部可进一步增加获益于存储器重用技术的机会。同样，减少或限制功能/工作负载的“写-集”可以有助于确保写容适在存储器重用技术内的分级区，并且可导致在写-集开始增长时与避免存储器重复相关联的开销的减少。

现在转向图25a，增强的faas系统2540可包括一个或多个瞬态功能(包括功能f和功能g)和一个或多个功能的目标系统2550。每一功能f或g具有与其不同的数据和代码区段相关联的不同的存储器区域(在图25a中被示为不同地阴影化的区域)。智能编排器/调度器的一些实施例可动态地且无缝地采样被高度使用的重复存储器区域(数据和代码两者)，将它们与正在运行的功能进行关联，并且在将来调度场景中使用这些结果。例如，一些实施例可以标识功能f、g中的共享信息2542，并将功能f、g路由到相同的目标系统2550(例如，因为目标系统2550可能已经加载了共享信息2542)。

现在转向图25b，提供功能即服务的方法2530的实施例可包括：在框2531标识对应于瞬态功能的共享信息，以及在框2532基于所标识的共享信息将该瞬态功能路由到执行环境。例如，框2531可包括标识具有相同语言的功能和/或彼此相似的功能的调度器和/或编排器，且因此将利用相同的底层共用数据集。例如，使用相同数据(例如，相同的地图、或流传输相同的视频、相同的计算机语言库等)的功能可以被标识为利用相同的底层共用数据集(例如，共享信息)。所标识的功能可以被调度为在相同的系统(例如，特定节点)或相同的系统池中执行。

方法2530的一些实施例可进一步包括：在框2533标识先前被路由的瞬态功能的新实例，以及在框2534将该新实例路由到与先前被路由的瞬态功能相同的执行环境。在一些实施例中，框2531可以扩展有框2535。例如，共享信息，如框2535所例示的，可包括共享代码、共享语言和共享数据中的一者或多者，并且可进一步包括由一个功能产生并由另一功能消耗的瞬态信息的共享。

方法2530的各实施例可在系统(诸如上文在图25a中描述的faas系统2540)、装置、计算机、设备等(举例来说诸如本文所描述的那些)中被实现。更具体地，方法2530的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法2530可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法2530可在结合下文示例2511至2513来描述的计算机可读介质上被实现。方法2530的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例2501包括一种电子处理系统，其包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，该逻辑用于：标识对应于瞬态功能的共享信息，以及基于所标识的共享信息将该瞬态功能路由到执行环境，其中所标识的信息被至少另一功能共享。

示例2502包括示例2501的系统，其中该逻辑进一步用于标识先前被路由的瞬态功能的新实例，以及将该新实例路由到与先前被路由的瞬态功能相同的执行环境。

示例2503包括示例2501至2502中的任一者的系统，其中该共享信息包括共享代码、共享语言、和共享数据中的一者或多者。

示例2504包括一种半导体封装装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地实现在可配置逻辑和固定功能硬件逻辑中的一者或多者中，耦合至该一个或多个衬底的逻辑用：标识对应于瞬态功能的共享信息，以及基于所标识的共享信息将该瞬态功能路由到执行环境，其中所标识的信息被至少另一功能共享。

示例2505包括示例2504的装置，其中该逻辑进一步用于标识先前被路由的瞬态功能的新实例，以及将该新实例路由到与先前被路由的瞬态功能相同的执行环境。

示例2506包括示例2504至2505中的任一者的装置，其中该共享信息包括共享代码、共享语言、和共享数据中的一者或多者。

示例2507包括示例2504至2506中任一者的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例2508包括一种提供功能即服务的方法，其包括：标识对应于瞬态功能的共享信息，以及基于所标识的共享信息将该瞬态功能路由到执行环境，其中所标识的信息被至少另一功能共享。

示例2509包括示例2508的方法，进一步包括标识先前被路由的瞬态功能的新实例，以及将该新实例路由到与先前被路由的瞬态功能相同的执行环境。

示例2510包括示例2508至2509中的任一者的方法，其中该共享信息包括共享代码、共享语言、和共享数据中的一者或多者。

示例2511包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：标识对应于瞬态功能的共享信息，以及基于所标识的共享信息将该瞬态功能路由到执行环境，其中所标识的信息被至少另一功能共享。

示例2512包括示例2511的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：标识先前被路由的瞬态功能的新实例，以及将该新实例路由到与先前被路由的瞬态功能相同的执行环境。

示例2513包括示例2511至2512中的任一者的至少一种计算机可读存储介质，其中该共享信息包括共享代码、共享语言、和共享数据中的一者或多者。

容器合并/分解和状态聚合和分解的示例

增强的faas系统(诸如上文结合图4所描述的增强的faas系统)的一些实施例可以有利地提供容器合并和/或分解，和/或状态合并和分解。各个功能常规地可以作为独立执行单元来对待，而不分析或计及各功能之间的关系，这有时候会导致资源未被优化或增加io开销(例如，网络和本地)。增强的faas系统的一些实施例可以有利地提供用于定义各功能之间的关系的功能调用图。一些相关的功能可以被内联，以避免多次功能调用。一些功能可以被分解以降低资源/带宽消耗。在一些实施例中，动态调用图可基于运行时分析来调整。增强的faas系统的一些实施例可以提供用于状态的动态表示和导航的数据本体。有利的是，增强的faas系统的一些实施例可以提供更好的资源利用、更低的io开销、和/或增加的带宽。一些实施例在不必要的时候可以不生成开销。在一些实施例中，开发人员可以标识在启动功能之前功能需要执行多久。

现在转向图26a，提供功能即服务的方法2630的实施例可包括：在框2631提供用于一个或多个瞬态功能的与组织有关的信息，诸如用于定义各功能之间的关系的功能调用图，以及在框2632基于与组织有关的信息来修改一个或多个瞬态功能的执行。方法2630的一些实施例可进一步包括在框2633将瞬态功能中的一者或多者拆分成一个或多个子功能。方法2630还可包括在框2634合并瞬态功能和子功能中的一者或多者。例如，方法2630可包括在框2635在瞬态功能和子功能中的一者或多者的执行之间共享状态信息。

方法2630的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法2630的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法2630可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法2630可在结合下文示例2614至2617来描述的计算机可读介质上被实现。方法2630的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

用于高效执行的容器合并/分解的示例

现在转向图26b，功能调用图2640的实施例可提供用于瞬态功能f、g和h的与组织有关的信息。如上所提及的，被标识为非独立的功能可以由于各功能之间的一个或多个依赖性而引起开销增加、差资源利用等。在图26b中示出的示例中，功能g和h取决于功能f，例如，功能g和h需要由功能f生成的至少一个输出以供执行。一些实施例可以有利地提供与组织有关的信息以用于高效功能执行，诸如功能调用图2640(例如，通过检测来标识何时一个功能导致另一功能)。

调用图可对应于表示各功能之间的调用关系的控制流图。在加权调用图中，每一弧线(例如，源自调用方功能且结束于被调用方功能)可以用该调用被调用的频率和/或概率来被加标签。调用图可以被静态地形成，且接着可以被动态地细化。基于调用图内形成的各区域，某些faas功能可以被合并以减少调用和数据通信的开销。例如，一些实施例可以将faas功能内的控制流图纳入调用图中，以使得某些faas功能可以被拆分成两个或更多个功能。

现在转向图26c到26e，例示图示出了功能f可如何被拆分成两个子功能f0和f1(参见图26c)，且随后功能g可如何在两个子功能之间被合并(参见图26d和26e)。这一分解和合并过程可有助于形成紧凑和/或高效的操作序列。一些实施例可对核的高速缓存性能具有正面影响，并且还可降低用于同时使多个faas功能保持温暖/活跃的存储要求和开销。在冷路径被执行的情形中，可能仍然需要通过将恰适的代码/调用插入恰适的faas功能来预设不太频繁被采用的控制流路径和调用路径。

在一些实施例中，代码生成可以应用编译器技术(例如，从原始lambda的编译器/代码生成器)以形成用于增强指令级并行性(ilp)的超级块。超级块可对应于没有侧面入口的轨迹。例如，控制仅能从顶部进入，但可以在一个或多个出口点离开(例如，顶部单个入口，但有多个出口)。在一些实施例中，简档信息可以被用于从包括多个基本块的共用路径来构建超级块。

一些实施例可以由基础设施(例如，在调度之前)执行和/或在运行时由调度器执行。一些实施例还可利用数据的共处一处。例如，一些实施例可以将功能递送至数据，而非相反，因为移动数据的成本高于移动功能的成本。一些实施例可以利用内联技术。例如，在所标识的功能2将被功能1以某一合理的确定性来调用，则一些实施例可以将功能2的代码内联到功能1中，而非单独调用(例如，参见图26e)。在内联之后，faas系统不必去往外部来执行功能2，获得调度器，或下载功能。由此，内联可以增加增强的faas系统的效率和/或降低增强的faas系统的开销。在一些实施例中，调度器可以执行内联操作。在一些实施例中，即便在功能1与功能2内联以生成新的经合并的代码之后，原始功能1和功能2代码仍然被存储(例如，不被移除或删除)。通过这么做，原始功能1和2仍然保持独立性以彼此分开地执行。例如，如果在新的经合并的代码执行时发生错误，则存在内联被不正确地习性的可能性。在此情形中，原始功能1和2仍然被保留，并且可以通过单独的功能调用以非内联的方式独立于彼此来执行。

增强的faas系统的一些实施例可附加地或替换地利用外联技术。例如，一些实施例可以移除同一功能中不太可能被执行的那些部分(例如，从if-else语句中移除else语句，因为它几乎不会被执行)。被移除的部分可以被配置为单独的程序/功能。外联可以有利地提供每一功能的更小下载。动态概况分析可以标识代码中的路径的“热度”信息(例如，概率或频率)，并且将热度信息存储在增强的faas系统中以供使用。例如，同一功能的不同路径可以被标识，并且接着对照热度信息来参考以确定每一路劲该发生的可能性。具有高于阈值的相关联的热度信息(例如，发生的概率或频率)的路径被保留。不具有高于该阈值的热度信息的其他路径被移除，并且被置为单独的程序/功能。

在一个特定示例中，功能可具有“if-else”语句。热度信息指示“if”语句具有100％的执行概率，而“else”语句具有10％的执行概率。如果阈值被设置为30％概率，则该系统可以得出如下结论：“if”语句要被保留，但“else”语句要被移除且被置为单独的功能调用。然而，如果热度信息指示“else”语句概率为40％，则该系统可以得出以下结论：“else”语句不要被移除并且应当被保留。该阈值可以基于不同因素被动态地设置，该因素诸如可用硬件、高速缓存可用性、带宽可用性、功能的优先级信息(例如，功能是否具有高优先级且在短时间内完成时关键的，则不将功能拆分开)等。

增强的faas系统的一些实施例可以标识对相同的数据进行操作的功能(例如，其原本可能是不相关的)，并且将这些功能与数据放置在相同的位置中。一些实施例可以确定用于标识是否要执行任何合并/分解的度量(例如，对于所有功能而言最小5分钟执行时间)。

用于促成功能重用的状态聚合和分解的示例

许多faas框架可支持“纯净”或无状态的功能的重用的概念。因而，出于实用目的，可以用其内部状态恒定的功能的存储器布局来初始化容器，但是也可以向其提供新的输入作为传入参数。该无状态功能接着可产生输出(例如，其同样不是功能状态的一部分)。这种无状态并非总是有益的。有时候，可以通过被映射到恰巧更新共同状态的不同子模块的单个容器来最好地满足较大的意图(例如，代替总是将该意图分解为单独的功能，这些功能需要将数据从一个功能显式地移动到另一功能)。另外，如果所需功能的集合过大而无法容适到单个容器内，或者如果将容器拆分开对于模块化是合乎需要的，则从功能链中的一个功能到另一功能的所需的输出流动增加了大量数据移动和存储器管理开销。

现在转向图27a，增强的faas系统2700的实施例可包括存储器2710，其可以由两个或更多个子功能2720(例如，子功能a到n)通过利用与组织有关的信息(诸如描述符2730)来共享。增强的faas系统2700的一些实施例可以有利地提供用于避免容器的不必要分段的开销的技术。例如，数据本体可以提供状态的动态表示和导航。例如，要作为输出在逻辑上从一个功能被转移到另一功能的总状态量可以被划分成描述符的分层结构并且使用本体来描述。描述符的分层结构可以描述：根据各个子功能之间的共享本体，消耗功能中的总信息要如何被聚合。

结果，不必从前一功能x改变为下一功能y的状态信息原地停留在从x被传递到y的共用描述之后，而所有其他状态信息可以在y中作为该共用描述符之上的覆盖(例如，替换或扩展)来被对待。以此方式，各功能可以被有意地组织为在通过访问器技术访问的数据上进行操作，并且这些访问器技术可以使用描述符并执行任何需要的覆盖，以使得各个子功能中的每一者的主体本身保持无状态。例如，一些实施例可遵循“将功能应用到数据”的概念而不将数据从一个存储器区域移动到另一存储器区域。一些实施例可以取而代之在原地但是间接地通过被传递的描述符来对数据进行操作。

图27b示出了描述符2754的分层结构以及最终引用存储器2760中的对象1-6的第一和第二描述符组2756、2758的详细视图。描述符2754的分层结构以及描述符组2756和2758可以由编程人员显式地定义，或者可以从对功能2752和存储器2760中的对象执行的数据流分析隐式地被达成，并且其中此类数据流分析由编程人员显式地发起或由faas系统本身隐式地发起。在一些实施例中，编程人员可以显式地指定一些对象，并且生成和使用用于这些对象的描述符，并将它们置于分层结构中，而其他对象及其描述符可以通过在文件系统、符号表、数据库等中对象命名和引用机制的使用被组织成分层结构。图27b示出了两级描述符传递，虽然它也可能在分层结构中的其他级别执行其他类型的描述符传递。第一级描述符传递包括描述符2754。描述符2754展示将顶级描述符(例如描述符1)从子功能a传递到子功能b，以使得子功能b能够访问子功能a先前可访问的全部对象。例如，在子功能a完成执行之后，描述符1可以被传递到子功能b。第二级描述符传递包括第一和第二描述符组2756、2758。第一和第二描述符组2756、2758是可以通过第一级描述符传递被传递的新一代顶级描述符。第一和第二描述符组2756、2758中的每一者仅引用从描述符1引用的第二级描述符2-7中的一半。各种深度的各种描述符分层结构都是可能的。值得注意的是，第一级描述符2754还可以能够被修改以指向第一和第二描述符组2756、2758中的不同的描述符组。

附加注解与示例

示例2600包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：提供用于一个或多个瞬态功能的与组织有关的信息，基于该与组织有关的信息来修改该一个或多个瞬态功能的执行，其中该修改可包括该瞬态功能中的一者或多者拆分成一个或多个子功能以及该瞬态功能中的一者或多者的合并中的一者或多者，在瞬态功能和子功能中的一者或多者的执行之间共享状态信息，以及将瞬态功能和子功能中的一者或多者移动为与瞬态功能和子功能中的该一者或多者使用的数据共处一处。

示例2601包括一种电子处理系统，其包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，该逻辑用于：提供用于一个或多个瞬态功能的与组织有关的信息，以及基于该与组织有关的信息来修改该一个或多个瞬态功能的执行。

示例2602包括示例2601的系统，其中该逻辑进一步用于将瞬态功能中的一者或多者拆分成一个或多个子功能。

示例2603包括示例2601至2602中任一者的系统，其中该逻辑进一步用于合并瞬态功能和子功能中的一者或多者。

示例2604包括示例2601至2602中任一者的系统，其中该逻辑进一步用于在瞬态功能和子功能中的一者或多者的执行之间共享状态信息。

示例2605包括一种半导体封装装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地实现在可配置逻辑和固定功能硬件逻辑中的一者或多者中，耦合至该一个或多个衬底的逻辑用于：提供用于一个或多个瞬态功能的与组织有关的信息，以及基于该与组织有关的信息来修改该一个或多个瞬态功能的执行。

示例2606包括示例2605的装置，其中该逻辑进一步用于将瞬态功能中的一者或多者拆分成一个或多个子功能。

示例2607包括示例2605至2606中任一者的装置，其中该逻辑进一步用于合并瞬态功能和子功能中的一者或多者。

示例2608包括示例2605至2606中任一者的装置，其中该逻辑进一步用于在瞬态功能和子功能中的一者或多者的执行之间共享状态信息。

示例2609包括示例2605至2608中任一者的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例2610包括一种提供功能即服务的方法，其包括：提供用于一个或多个瞬态功能的与组织有关的信息，以及基于该与组织有关的信息来修改该一个或多个瞬态功能的执行。

示例2611包括示例2610的方法，进一步包括将瞬态功能中的一者或多者拆分成一个或多个子功能。

示例2612包括示例2610至2611中任一者的方法，进一步包括合并瞬态功能和子功能中的一者或多者。

示例2613包括示例2610至2611中任一者的方法，进一步包括在瞬态功能和子功能中的一者或多者的执行之间共享状态信息。

示例2614包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：提供用于一个或多个瞬态功能的与组织有关的信息，以及基于该与组织有关的信息来修改该一个或多个瞬态功能的执行。

示例2615包括示例2611的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：将瞬态功能中的一者或多者拆分成一个或多个子功能。

示例2616包括示例2614至2615中的任一者的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：合并瞬态功能和子功能中的一者或多者。

示例2617包括示例2614至2615中的任一者的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在瞬态功能和子功能中的一者或多者的执行之间共享状态信息。

容器值散列高速缓存示例

增强的faas系统的一些实施例可以有利地提供容器值散列高速缓存。容器值可对应于可以被存储在容器中的任何类型的数据(例如，kv-存储、文本、经压缩的可执行图像、功能调用中使用的参数、来自功能执行的结果等)。存储器是有限资源，而容器值占用存储器空间。一些容器值可以被许多功能使用，并且io带宽被要求以用于加载/重新加载此类容器值。一些实施例可以提供散列索引以减少访问共享容器值所需的存储器的量。在一些实施例中，共享容器值可以被加载到高速缓存中。一些实施例可以锁定一个或多个容器值以避免重新加载这些容器值的开销(例如，将容器值标记为被持久保留在高速缓存/存储器中)。

现在转向图28a，提供功能即服务的方法2830的实施例可包括：在框2831将共享容器值存储在在两个或更多个瞬态功能之间共享的散列表中，以及在框2832通过散列索引来访问存储在共享散列表中的共享容器值。方法2830的一些实施例可进一步包括在框2833高速缓存共享散列表。方法2830还可包括在框2834将共享容器值锁定在共享散列表中。

方法2830的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法2830的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法2830可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法2830可在结合下文示例2811至2813来描述的计算机可读介质上被实现。方法2830的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

增强的faas系统(诸如下文结合图28b描述的增强的faas系统2840)的一些实施例可以有利地提供容器值散列高速缓存。在一些其他faas系统中，重复的常数不在各个功能之间被共享。各个功能在一些其他faas系统中被不同地对待，以使得各个功能不共享值。增强的faas系统2840的一些实施例可以有利地提供用于存储由容器利用的共享常量的散列表。各个功能可以有利地引用散列表，藉此节省原本加载共享容器值可能需要的io带宽、存储器空间、功率利用、计算资源等。

现在转向图28b，增强的faas系统2840的实施例可包括散列表2842，散列表2842可以由一个或多个瞬态功能2844共享。散列表2842可以通过散列值(例如，h1到hn)来索引以返回对应的共享容器常量值(例如，c1到cn)。

增强的faas系统2840的一些实施例可以提供常量值高速缓存，该常量值高速缓存可以在进程/lambda/容器启动时被填充并可在单独高速缓存中存储大常量值(例如，用于计算快速傅里叶变换(fft)的旋转因子、神经网络滤波器值等)。例如，六十四(64)个不同的双浮点常量(例如，每一个都是64位)，一些实施例可以使用六(6)位索引来访问它们(例如，用于索引64个不同的常量的2⁶个索引值)。这些值可以是编译时或加载时(例如，在向温暖的神经网容器注入推理lambda时)常量。编译器/jit/代码生成器可以首先在开始lambda/容器初始化时用专用存储指令将常量值加载到常量值高速缓存。随后，对应于常量值的常规加载可以由指示到常量值高速缓存的索引的专用加载指令来替代。增强的faas系统2840的一些实施例可以有利地通过更紧凑的加载编码来改进高速缓存性能。例如，用于存储器引用所要求的特定架构指令格式的一些字段(例如，指定寻址模式的mod字段、以及指定用于计算存储器地址的比例、索引和基址的sib字段)对于对常量值高速缓存的引用而言可能是不必要的。一些实施例还可以释放存储器排序缓冲器(mob)条目，并且移除对用于从常量值高速缓存的加载指令读取的存储转发等的校验的要求。

增强的faas系统2840的一些实施例还可确保常量被锁定在常量值高速缓存中且不会被踢出。例如，卷积神经网络(cnn)滤波器值在推理期间可以被非常频繁地使用。滤波器值可以是常量，但是大量的输入/输出通道可能使得cnn的工作集远大于高速缓存的容量。结果，滤波器值无法驻留在高速缓存内，并且在一些其他系统中，可能在若干不同的功能调用内每一次都从存储器被带回，这可能是昂贵的并影响性能。在增强的faas系统2840的一些实施例中，常量值高速缓存可以被加载一次，并在多个lambda/进程之间共享(例如，包括使用同一cnn滤波器值的多个推理lambda)，这可以有利地节省计算、存储器、和/或io资源。

附加注解与示例

示例2801包括一种电子处理系统，其包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，该逻辑用于：将共享容器值存储在在两个或更多个瞬态功能之间共享的散列表中，以及通过散列索引来访问存储在共享散列表中的共享容器值。

示例2802包括示例2801的系统，其中该逻辑进一步用于高速缓存该共享散列表。

示例2803包括示例2801至2802中的任一者的系统，其中该逻辑进一步用于将共享容器值锁定在共享散列表中。

示例2804包括一种半导体封装装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地实现在可配置逻辑和固定功能硬件逻辑中的一者或多者中，耦合至该一个或多个衬底的逻辑用于：将共享容器值存储在在两个或更多个瞬态功能之间共享的散列表中，以及通过散列索引来访问存储在共享散列表中的共享容器值。

示例2805包括示例2804的装置，其中该逻辑进一步用于高速缓存该共享散列表。

示例2806包括示例2804至2805中任一者的装置，其中该逻辑进一步用于将共享容器值锁定在共享散列表中。

示例2807包括示例2804至2806中任一者的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例2808包括一种提供功能即服务的方法，其包括：将共享容器值存储在在两个或更多个瞬态功能之间共享的散列表中，以及通过散列索引来访问存储在共享散列表中的共享容器值。

示例2809包括示例2808的方法，进一步包括高速缓存该共享散列表。

示例2810包括示例2808至2809中任一者的方法，进一步包括将共享容器值锁定在共享散列表中。

示例2811包括至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：将共享容器值存储在在两个或更多个瞬态功能之间共享的散列表中，以及通过散列索引来访问存储在共享散列表中的共享容器值。

示例2812包括示例2811的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：高速缓存该共享散列表。

示例2813包括示例2811至2812中任一者的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：将共享容器值锁定在共享散列表中。

逆转/撤销容器的示例

增强的faas系统的一些实施例可以有利地提供逆转/撤销容器。在faas系统中，取消请求或崩溃可能使一些资源处于不确定的状态。在一些实施例中，逆转/撤销功能可以被注册以清除受到崩溃/取消请求影响的资源。一些实施例可以提供更好的资源利用和/或更少的不确定状态。

现在转向图29a，提供功能即服务的方法2930的实施例可包括：在框2931确定瞬态功能是否具有相关联的清除功能，以及在框2932在瞬态功能被中断的情况下执行相关联的清除功能。方法2930的一些实施例可进一步包括在框2933自动生成清除功能。方法2930还可包括在框2934自动注册该清除功能。

方法2930的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法2930的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法2930可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法2930可在结合下文示例2911至2913来描述的计算机可读介质上被实现。方法2930的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

一些faas系统可以被认为是无状态的。“无状态”faas系统的一个示例是不存在正由faas系统执行的功能的监视状态。如果系统或功能崩溃，则因为没有记录的状态可能会发生问题。例如，如果功能修改了一些数据并接着崩溃了，则系统可能无法确定要从哪里拾取该功能或要如何继续完成该功能，清除并重新开始(例如，faas系统不知道要撤销什么数据)。增强的faas系统(诸如图29b中示出的增强的faas系统)的一些实施例可以有利地提供用于撤销破坏的专用功能作为对原始功能的逆转(例如，补充性的或被包括在同一功能中)。

现在转向图29b，增强的faas系统2940的实施例可调用功能f(x)，其可以在执行之前被中断。例如，此类中断可对应于功能的取消、功能f(x)的崩溃、faas系统2940的崩溃、所需资源的缺失等。在中断之后，faas系统2940的一些实施例可以调用清除功能f^-1(x)以解决由功能f(x)的中断引起的一个或多个问题。例如，功能f^-1(x)可以被认为是撤销功能、逆转功能、反向功能等。

传统的faas功能(例如，亚马逊web服务(aws)lambda^tm)被认为是无状态的，其可具有一些外部可见的副作用。例如，lambda功能可以更新数据库条目或调用其本身可具有某些外部可见的副作用的另一lambda功能。例如，用于货物递送的订单可调用一系列faas功能/lambda功能。如果该订单在任何时间点被取消，则取消请求需要被传播并且某些更新/动作可能需要被撤销。增强的faas系统2940的一些实施例可以通过用原始参数(诸如json对象)来调用相同但用于撤销副作用等的链来执行撤销功能。

增强的faas系统2940的一些实施例可以注册要代替实际lambda被调用以清除副作用的faas功能/lambda功能的反转/撤销版本，并且撤销lambda功能可以由应用开发人员来提供或者可以由代码生成器自动生成。例如，撤销lambda功能可包括撤销日志记录的组合，并且可以以自底向上、模块化的方式利用回退切片生成(例如，类似于用于删除成员对象的c++解构器调用)。

附加注解与示例

示例2901包括一种电子处理系统，其包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，该逻辑用于：确定瞬态功能是否具有相关联的清除功能，以及在瞬态功能被中断的情况下执行相关联的清除功能。

示例2902包括示例2901的系统，其中该逻辑进一步用于注册该清除功能。

示例2903包括示例2901至2902中任一者的系统，其中该逻辑进一步用于自动生成清除功能。

示例2904。一种半导体封装装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地实现在可配置逻辑和固定功能硬件逻辑中的一者或多者中，耦合至该一个或多个衬底的逻辑用于：确定瞬态功能是否具有相关联的清除功能，以及在瞬态功能被中断的情况下执行相关联的清除功能。

示例2905包括示例2904的装置，其中该逻辑进一步用于注册该清除功能。

示例2906包括示例2904至2905中任一者的装置，其中该逻辑进一步用于自动生成清除功能。

示例2907包括示例2904至2906中任一者的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例2908。一种提供功能即服务的方法，其包括：确定瞬态功能是否具有相关联的清除功能，以及在瞬态功能被中断的情况下执行相关联的清除功能。

示例2909包括示例2908的示例，进一步包括注册该清除功能。

示例2910包括示例2908至2909中任一者的方法，进一步包括自动生成清除功能。

示例2911。至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：确定瞬态功能是否具有相关联的清除功能，以及在瞬态功能被中断的情况下执行相关联的清除功能。

示例2912包括示例2911的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：注册该清除功能。

示例2913包括示例2911至2912中任一者的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：自动生成清除功能。

容器的持续传递样式的示例

增强的faas系统(诸如图4中示出的增强的faas系统)的一些实施例可以有利地提供用于容器的持续传递样式。faas功能是独立的执行单元，并且在不同的faas功能具有某种关系时(例如，在各功能之间传递数据)可能发生额外开销。增强的faas系统的一些实施例可以提供向下传递能力以在功能调用之间移交信息。在一些实施例中，附条件的功能调用可以是向下传递数据的一部分。有利的是，一些实施例可以提供更好的资源利用、减少的io带宽、和/或更快的执行。

现在转向图30a，提供功能即服务的方法3030的实施例可包括：在框3031执行瞬态功能，该瞬态功能包括作为瞬态功能的参数的持续功能，以及在框3032执行来自该瞬态功能的持续功能。方法3030的一些实施例可进一步包括在框3033递归地向下传递用于该持续功能的代码、上下文和数据中的一者或多者。例如，方法3030可包括在框3034将恢复代码作为该持续功能的一部分向下传递。

方法3030的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法3030的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法3030可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

例如，方法3030可在结合下文示例3011至3013来描述的计算机可读介质上被实现。方法3030的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

在一些faas系统中，功能是独立的功能单元，并且由于不同委托策略可能影响性能，因此在不同功能之间可能出现委托问题。如图30b所示的增强的faas系统3040的一些实施例可以有利地将持续功能(诸如lambda功能或另一功能)传递到另一被调用方功能以改进功能执行性能。这可以被认为是一种用于跨多个功能实施“幂等性”的机制，并且可以更高性能地来执行幂等功能。如果具有副作用的功能所访问的系统状态和/或底层数据在该功能的所有实例完成执行之后具有相同的值，而无论该功能在没有与其他功能的任何交织执行的情况下被调用多少次，则该功能可以被认为是幂等的。各个功能可以初始地被认为是无副作用的，但是存在其中各个功能修改外部共享的资源(例如，数据库和/或数据结构)藉此导致副作用的用例。考虑功能调用的异步特性，本文所讨论的办法将变异操作(例如，修改外部共享资源(诸如数据库和/或数据结构)的功能)的执行委托给调用链内的最后一个功能。

现在转向图30b，增强的faas系统3040的实施例可包括递归功能调用，其中功能f可以向下传递数据和代码以调用功能g，功能g可以向下传递数据和代码以调用功能h，并以此类推。即，每一持续功能用父功能的当前功能状态来更新，并且接着进一步将该持续功能的当前功能状态向下传递至子功能。因此在所例示的示例中，功能f将当前功能状态数据(cont_f)向下传递至功能g。即，“cont_f”调用功能g，并且被认为是功能f的当前功能状态。功能g接收到功能f的当前功能状态，将功能状态更新为同样调用功能h的“cont_f.g.”，并且以此类推。因而，各个调用还用于维持功能状态的清晰对应关系，以使得反向工程和/或调试是可能的。

增强的faas系统3040的一些实施例可以向功能调用增加技术/能力以能够将代码、数据、上下文等向下传递至被调用方功能。被调用方功能接着可递归地向下传递代码、数据、上下文等。例如，功能g是将数据传递至功能g的功能f的被调用方，功能h是将数据传递至功能h的功能g的被调用方。增强的faas系统3040的一些实施例可以有利地实现某些动作(例如，具有外部可视副作用的动作)的延迟执行直到某些要求被满足。增强的faas系统3040的一些实施例还可通过功能状态的以上对应关系实现在功能调用链期间发生某些异常/条件的情况下向下传递要被执行的恢复/回滚代码。有利的是，增强的faas系统3040的一些实施例可以有助于实现弹性解决方案并实现正确/高效的异常处置。

增强的faas系统3040的一些实施例可支持持续传递样式，其中上下文和数据结构可以作为标准数据互换格式(诸如协议缓冲器)来传递。要被执行的代码可以被封装在lambda功能中，并且lambda地址/id也可以连同上下文一起被传递。在一些实施例中，lambda代码的恢复/延迟的副作用可以由编译器/代码生成器从原始lambda中提取。

附加注解与示例

示例3001包括一种电子处理系统，其包括：处理器、通信耦合至该处理器的存储器、以及通信耦合至该处理器和该存储器的逻辑，该逻辑用于：执行瞬态功能，该瞬态功能包括作为瞬态功能的参数的持续功能，以及执行来自该瞬态功能的持续功能。

示例3002包括示例3001的系统，其中该逻辑进一步用于递归地将用于该持续功能的代码、上下文和数据中的一者或多者向下传递。

示例3003包括示例3001至3002中任一者的系统，其中该逻辑进一步用于将恢复代码作为该持续功能的一部分向下传递。

示例3004包括一种半导体封装装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑至少部分地在可配置逻辑和固定功能硬件逻辑中的一者或多者中实现，耦合至该一个或多个衬底的逻辑用于：执行瞬态功能，该瞬态功能包括作为瞬态功能的参数的持续功能，以及执行来自该瞬态功能的持续功能。

示例3005包括示例3004的装置，其中该逻辑进一步用于递归地将用于该持续功能的代码、上下文和数据中的一者或多者向下传递。

示例3006包括示例3004至3005中任一者的装置，其中该逻辑进一步用于将恢复代码作为该持续功能的一部分向下传递。

示例3007包括示例3004至3006中任一者的装置，其中耦合至该一个或多个衬底的逻辑包括位于该一个或多个衬底内的晶体管沟道区。

示例3008。一种提供功能即服务的方法，其包括：执行瞬态功能，该瞬态功能包括作为瞬态功能的参数的持续功能，以及执行来自该瞬态功能的持续功能。

示例3009包括示例3008的方法，进一步包括递归地将用于该持续功能的代码、上下文和数据中的一者或多者向下传递。

示例3010包括示例3008至3009中任一者的方法，进一步包括将恢复代码作为该持续功能的一部分向下传递。

示例3011。至少一种计算机可读存储介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：执行瞬态功能，该瞬态功能包括作为瞬态功能的参数的持续功能，以及执行来自该瞬态功能的持续功能。

示例3012包括示例3011的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：递归地将用于该持续功能的代码、上下文和数据中的一者或多者向下传递。

示例3013包括示例3011至3012中任一者的至少一种计算机可读存储介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：将恢复代码作为该持续功能的一部分向下传递。

方便的容器构造和高速缓存管理的示例

faas系统可以是伴随周期性和随机事件的事件驱动模型。由此，通常发生这样的一种情况，其中相同的功能和/或利用相同或相似容器的功能，该容器包括功能在执行期间将利用的数据集(例如，数据对象)。各功能可以在短时间跨度中被执行若干次。在一些架构中，可以在每一功能执行时都使用新容器，除非其中容器可以通过温暖容器办法被重用的一些情形。保持温暖容器可能不必要地消耗资源。例如，温暖容器可以在等待功能以供执行的同时保持空闲。空闲时间可以是无生产力的。此外，容器重用或共享可以特定于某一容器的，并且可能无法适用于所有情景。

作为对比，温暖容器可以被拆除，而在功能被调用时冷容器可以被启动。构建、发起或启动容器可包括若干阶段，诸如配置名称空间和控制组、设置网络、以及设置执行环境。执行环境可包括用户数据和其他要求。一些其他要求可包括各种密钥、cpu/存储器/盘容量保留或优先级、数据库、数据集、密钥值存储、转换词典、资源使用信用等。其他要求的进一步示例还可包括神经网络、已经被打开过一次并且接着被高速缓存以供重用的文件或网络描述符，和/或可执行文件的被高速缓存的经解析的镜像。

如上所述，容器启动时间(冷容器启动)具有并非微不足道的等待时间，并且消耗资源。容器启动时间可以影响faas性能，并且启动时间的减少是合乎需要的。

现在转向图31a，例示了faas示例3100，其中容器可以以方便的方式被重建，而无需利用温暖容器和/或甚至存储构建容器所需的全部数据。示例3100的增强的faas架构可包括高速缓存3102、高速缓存控制器3104、保留策略管理器3106和启动计时器3108。高速缓存3102、高速缓存控制器3104、保留策略管理器3106和启动计时器3108可以是同一计算节点(例如，计算设备、服务器、移动设备等)的一部分。如下文更详细地说明的，增强的faas架构可以标识容器的子集，并且存储该子集而非回收或拆除整个容器。该子集可以被称为工作集。通过这么做，温暖容器可以被拆除以降低资源消耗，并且容器可以在需要时被快速重建以减少等待时间。

因而，容器的资源可以被称为工作集。因而，在允许容器的较少活跃部分被移除的同时，“热”活跃工作集要被存储在高速缓存3102中。例如，共享工作集可以是在各个功能之间被共享的集，并且可包括权重、常量、公式、共用数据(例如，名称、图像、地图等)的数据库、用户输入、各种密钥、cpu/存储器/盘容量保留或优先级、数据集、密钥值存储、转换词典、资源使用信用、神经网络、已经被打开过一次并且接着被高速缓存以供重用的文件或网络描述符、和/或可执行文件的被高速缓存的经解析的镜像。此类工作集可以被保持在高速缓存3102中，且由faas架构管理以准予对工作集的访问。每一工作集可以被指派一存活时间，该存活时间在每一次一个功能访问该工作集时被延长。可以基于数据的使用频率(如下说明的)以及在没有该工作集的情况下发起容器的启动时间的测量、以及存活时间来从高速缓存3102中驱逐工作集。例如，如果工作集具有大使用频率，则该工作集可以被维持，即便设置时间是短的。

如所例示的，高速缓存3102包括存储以下两个工作集的高速缓存空间3112：c(1)工作集(其也可以被称为数据对象)和c(2)工作集(其也可以被称为数据对象)。c(1)是用于第一容器的缩写，而c(2)是用于第二容器的缩写。第一和第二容器可包括各个功能在执行期间利用的数据集。c(1)工作集是用于第一容器的工作集，而c(2)是用于第二容器的工作集。在该示例中，第一和第二容器两者均已经被拆除并且是非活跃的(例如，未被构建)。在第一和第二容器被拆除时，c(1)和c(2)工作集被维持在高速缓存空间3112中以在被调用时快速地构建第一和第二容器。即，c(1)工作集可以被用于构建第一容器，而c(2)工作集可以被用于构建第二容器。

因而，将c(1)和c(2)工作集维持在高速缓存空间3112中可以加速各个功能在第一或第二容器中的后续执行。即，第一和第二容器可以至少部分地基于c(1)和c(2)工作集被重建。在一些实施例中，c(1)和c(2)工作集可分别包括用于构建第一和第二容器的全部数据。在一些实施例中，c(1)和c(2)工作集可分别仅包括用于构建第一和第二容器的数据的子集。例如，一些数据对于若干不同容器而言可以是共用的。此类数据可以被存储为c(1)和c(2)工作集，且由此c(1)和c(2)工作集可以各自被用于构建若干不同的容器。在一些实施例中，c(1)和c(2)工作集可分别包括用于开始第一和第二容器的构建的数据对象，而用于构建第一和第二容器的数据的剩余部分对象在第一和第二功能被构建时抵达。

在一些实施例中，第一或第二容器可需要进一步的数据以支持功能的执行。即，取决于功能的要求，完全构建的第一或第二容器可能无法支持功能。因而，第一或第二容器可以被构建并修改为包括进一步的数据，并且允许经修改的第一或第二容器支持功能。该进一步的数据可以从数据源(例如，另一计算节点、数据库服务器等)接收。c(1)和c(2)工作集的大小以及第一和第二容器启动时间对于不同功能是不同的，尤其在第一容器和第二容器要用进一步的数据被扩充以促成执行的情况下。

一些驱逐策略可以几乎仅仅基于使用频率以及新数据是否要被存储。在faas环境中，容器启动时间(其可等效于功能启动时间)是并非微不足道的，且因此可能需要在驱逐期间被考虑。因而，3100的示例具有用于c(1)和c(2)工作集的增强的驱逐策略以考虑启动时间并增强容器启动。

如所例示的，提供启动计时器3108。启动计时器3108可以测量第一和第二容器的启动时间，并且将测得的启动时间(例如，构建时间)作为t(1)和t(2)存储在表3114中。例如，构建时间t(1)是用于构建第一容器(初始执行)的时间测量。第一容器可以在第一容器能够开始功能的执行时被认为完全构建。类似地，构建时间t(2)(初始执行)是用于构建第二容器的时间测量。第二容器可以在第二容器能够开始功能的执行时被认为完全构建。表3114可以是用于存储正被构建的每一容器的工作集及其构建时间的数据结构。

增强的高速缓存控制器3104可以控制从高速缓存3102的驱逐。高速缓存控制器3104可以访问表3114，或者从启动计时器3108接收包括存储在表3114中的信息的消息。高速缓存控制器3104可以在确定从高速缓存3102的驱逐时利用构建时间t(1)和t(2)。因而，高速缓存控制器3104可以在确定是否要驱逐c(1)工作集或c(2)工作集时利用第一和第二容器的构建时间t(1)和t(2)。

例如，高速缓存控制器3104可包括驱逐策略管理器3110。驱逐策略管理器3110可以基于构建时间t(1)和t(2)来生成不同的加权公式，并且将此类值存储在表3116中。例如，驱逐策略管理器3110可以构建用于c(1)工作集的第一加权公式。第一加权公式可包括加权函数f(t(1))。f(t(1))可以是接受构建时间t(1)作为输入并且输出从构建时间t(1)导出的值的函数。同样地，生成用于c(2)工作集的第二加权公式。第二加权公式可包括函数f(t(2))。函数f(t(2))可以是接受构建时间t(2)作为输入并且输出从构建时间t(2)导出的值的函数。表3116存储第一和第二加权公式。

第一和第二加权公式两者均还可包括进一步的值。例如，第一加权公式可包括函数k(1,ac(1))，其可以是基于c(1)工作集的访问频率ac(1)的另一函数。例如，函数k(1)可以接受c(1)工作集的访问数ac(1)作为输入以产生输出。同样地，函数k(2)可以接受c(2)工作集的访问数ac(2)作为输入以产生输出。第一和第二加权公式还可包括其他值。第二和第二加权公式可以是以上函数的加总。

驱逐策略管理器3110可以引用第一和第二加权公式来确定是否要从高速缓存3102中驱逐c(1)工作集或c(2)工作集。例如，驱逐策略管理器3110可以确定作为第一加权公式的合计计算的第一最终值，以及作为第二加权公式的合计计算的第二最终值。第一和第二最终值可以被存储在驱逐策略管理器3110的表3116中。驱逐策略管理器3110可以比较第一和第二最终值以确定是否要驱逐c(1)和c(2)工作集。因而，驱逐策略管理器3110将构建时间t(1)和t(2)和/或对c(1)和c(2)工作集的访问数ac(1)和ac(2)彼此比较。

作为示例，第一和第二最终值可以分别与第一和第二容器的启动时间以及分别与对c(1)和c(2)工作集的数据访问数ac(1)和ac(2)成比例。因而，如果第一最终值大于第二最终值，则c(1)工作集可以比c(2)工作集被更多地访问，和/或第一容器相对于第二容器可具有更高的启动时间。因而，驱逐c(1)工作集相对于驱逐c(2)工作集会导致更大的总等待时间。由此，驱逐策略管理器3110可以基于第一和第二最终值来驱逐c(2)工作集。因而，驱逐策略管理器3100可以驱逐与最小最终值相关联的工作集。

高速缓存控制器3104还可包括保留策略管理器3106。保留策略管理器3106可生成不同的加权公式以确定用于c(1)和c(2)工作集的存活时间。该存活时间可以被存储在表3118中。例如，保留策略管理器3106可以构建用于第一容器的第三加权公式。第三加权公式可包括函数g(t(1))，其是接受构建时间t(1)和函数l(1)作为输入以输出从构建时间t(1)导出的值的函数。同样地，生成用于第二容器的第四加权公式。第四加权公式可包括函数g(t(2))或即接受构建时间t(2)和函数l(2)作为输入以输出从构建时间t(2)导出的值的函数。第三和第四加权公式还可包括其他值，诸如常量和/或分别对于c(1)和c(2)工作集的数据访问数。从第三加权公式导出的值可以是用于c(1)工作集的存活时间，而从第四加权公式导出的值可以是用于c(2)工作集的存活时间。表3118示出了第三和第四加权公式。

在一些实施例中，保留策略管理器3106仅确定用于工作集的“存活时间”。保留策略管理器3106因此实质上使得驱逐策略管理器3110能够作出关于不单单基于存活时间的排定优先级的驱逐的更详尽的决策。在一些实施例中，保留策略管理器3106的结果可以被驱逐策略管理器3110用来作出更详尽的驱逐决策，且是第一和第二加权公式中的因子。在此类实施例中，保留策略管理器3106可以不从高速缓存3102中驱逐数据，但是关于此类决策听从驱逐策略管理器。

在一些实施例中，保留策略管理器3106和驱逐策略管理器3110可以彼此独立地操作以按需移除c(1)和c(2)工作集。例如，驱逐策略管理器3110可以响应于高速缓存3102已满且对于另一faas功能而言需要更多空的空间的确定而被触发以驱逐数据。驱逐策略管理器3110接着可以如上所述地确定要驱逐c(1)工作集还是c(2)工作集。保留策略管理器3106可以简单地标识存活时间何时期满，并且驱逐对应的c(1)工作集或c(2)工作集，而不管高速缓存3102中空的空间量有多少。即，驱逐策略管理器3110可以由高速缓存3102中需要更多空的空间的标识被触发以移除工作集，而保留策略管理器3106可以不被此类标识触发。

在一些实施例中，每一工作集c(1)和(c2)可具有单独的计时器。可以将计算所得的存活时间值对照计时器作比较。当用于工作集c(1)和(c2)之一的一个计时器满足一个工作集的存活时间值时，该一个工作集可以被驱逐。作为示例，在对应的存活时间超时的时候，如计数器所计数的且由保留策略管理器3106所标识的那样，则c(1)工作集或(c2)工作集可以被驱逐。计时器可以在每次c(1)或(c2)工作集被访问时被重置。例如，如果c(1)工作集被访问，则用于c(1)工作集的计时器将被重置。作为对比，c(2)工作集计时器可以不被重置，因为c(2)没有被访问。计时器还可以响应于释放资源或对选择的请求类别给予高优先级的需要的标识而被自动地和/或以管理方式重置。在一些实施例中，计时器可以不被重置，并且存活时间表示最大存活时间。

高速缓存3102可以是硬件高速缓存(例如，llc、tlb)或软件对象高速缓存(例如，java持久对象高速缓存)。高速缓存3102例如可以是页高速缓存。此外，高速缓存控制器3104可以控制若干高速缓存或若干级的高速缓存。此外，驱逐事件可以由缺少用于传入数据的存储空间而触发，且由高速缓存控制器3104监视。

作为示例，第一容器可以执行用于图像识别的第一功能，而第二容器可以执行用于图像旋转的第二功能。用于第一功能的图像识别启动可涉及初始化第一容器的神经网络。因此，用于第一容器的构建时间t(1)可以显著高于用于第二容器的构建时间t(2)。图像识别的存储器印记可以更高，而使容器保持存活以供重用可能是高成本的。此外，图像识别的执行频率可能低于图像旋转功能。因而，对第一容器的数据的访问数可能低于第二容器。然而，从性能角度来说，由于构建时间t(1)显著高于构建时间t(2)，驱逐策略管理器3110可以确定驱逐c(1)工作集(例如，图像识别容器)可能不是有益的，并且确定驱逐c(2)工作集(图像旋转容器)。此外，维持c(1)工作集可以增强第二容器启动，因为来自c(1)工作集的数据可以被标识为对于第一和第二容器而言是共用的且在第二容器的构建期间被利用。因此，驱逐策略管理器3110可以在高速缓存驱逐策略中考虑启动时间。

进程3120可驱逐c(2)工作集以容适传入c(3)工作集。c(3)工作集可以是用于构建第三容器的数据，且包括与上文参照c(1)和c(2)工作集所描述的数据类似的数据。图31b可以是图31a所例示的场景3100的延续。如图31b中所例示的，c(2)数据集和相关联的数据从高速缓存空间3112、表3114、表3116和表3118中被擦除。高速缓存空间3112、表3114、表3116和表3118存储用于第三容器的数据和c(3)工作集，其可以类似于上述的对应数据。

图31c示出了增强的高速缓存驱逐方法3150，且可以在图31a和31b的增强的faas服务器架构和/或一个或多个模块中被实现为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法3150中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框3152可以在功能的初始执行期间测量启动时间。初始执行可以仅包括构建用于执行功能的容器。例如，启动时间可以仅从开始容器构建起直到容器被构建并准备好用于执行功能来进行测量。所例示的处理框3154可以基于该启动时间来生成一个或多个权重。该一个或多个权重可以与启动时间成比例。所例示的处理框3156可以利用该一个或多个权重来驱逐数据。例如，该一个或多个权重可以按加权算法和/或方案来使用以计算最终值并基于该最终值来驱逐数据，该最终值指示容器的工作集在高速缓存中的利用。例如，如果最终值高于另一最终值(如本文所述地类似地计算所得)，则该工作集可以不从高速缓存中被驱逐，而对应于该另一最终值的一个不同的工作集可以被驱逐。因而，方法3150可以增强高速缓存驱逐。

图31d示出了增强的高速缓存驱逐方法3170，且可以在图31a和31b的增强的faas服务器架构和/或一个或多个模块中被实现为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法3170中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框3172可以测量用于第一容器的第一设置时间。在第一容器被设置(例如构建)之后，第一功能可以在第一容器中执行。第一设置时间可以是用于配置第一容器的一个或多个名称空间以及第一容器的一个或多个控制组以及设置执行环境的时间。所例示的处理框3174可以测量用于第二容器的第二设置时间。在第二容器被设置(例如构建)之后，第二功能可以在第二容器中执行。第二设置时间可以是用于配置第二容器的一个或多个名称空间以及第二容器的一个或多个控制组以及执行环境的时间。第二功能可以与第一功能不同，并且第一和第二容器可以彼此不同。

所例示的处理框3176可以测量第一数据集的第一使用(例如访问)频率。第一数据集可以是用于构建第一容器的数据。所例示的处理框3178可以测量第二数据集的第二使用(例如访问)频率。第二数据集可以是用于构建第二容器的数据。访问可以意味着读和/或写。

所例示的处理框3180可以基于第一设置时间与第二设置时间的比较来从高速缓存中驱逐数据对象。此外，所例示的处理框3180可以基于第一使用频率测量与第二使用频率测量的比较来从高速缓存中驱逐数据对象。在第二设置时间高于第一设置时间时，数据对象可以与第一容器相关联。例如，第一设置时间可以小于第二设置时间，并且第一使用频率可高于第二使用频率达微弱量。尽管第一使用频率更高，但由于第一设置时间低于第二设置时间，可以驱逐第一容器的数据对象(例如，第一数据集)。数据对象可以是或可以包括发起第一容器的第一数据集。

在一些实施例中，如果第一使用频率高于第二使用频率达足够大的幅值，则与第二容器相关联的数据对象(例如第二数据集)而非第一容器的数据对象可以被驱逐，尽管第二设置时间高于第一设置时间。例如，如果第一使用频率高于第二使用频率达预定量或高于一比率，则与第二容器相关联的数据对象可以被驱逐。在一些实施例中，如果数据对象(例如，数据集)的使用频率落在某一阈值以下，则该数据对象可以被驱逐而不考虑启动时间。因而，方法3170可以增强高速缓存驱逐并减少功能执行的等待时间。

图31e示出了增强的高速缓存驱逐方法3190，且可以在图31a和31b的增强的faas服务器架构和/或一个或多个模块中被实现为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法3190中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框3192可以测量用于第一容器的第一设置时间。如所讨论的，第一设置时间可以是用于构建第一容器的时间。所例示的处理框3194可以测量用于第二容器的第二设置时间。如所讨论的，第二设置时间可以是用于构建第二容器的时间。所例示的处理框3196可以基于第一设置时间来确定第一容器的数据对象的存活时间。数据对象可以被存储在高速缓存中。所例示的处理框3196可以基于第二设置时间来进一步确定第二容器的数据对象的存活时间。第二容器的数据对象可以被存储在高速缓存中。尽管未例示，但是在存活时间期满的情况下第一和第二对象可以被驱逐。

附加注解与示例

示例3100包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：测量用于第一容器的第一设置时间，其中第一功能用于在第一容器中执行，其中第一设置时间是用于配置第一容器的一个或多个名称空间以及第一容器的一个或多个控制组的时间，测量用于第二容器的第二设置时间，其中第二功能用于在第二容器中执行且第二功能与第一功能不同，其中第二设置时间是用于配置第二容器的一个或多个名称空间以及第二容器的一个或多个控制组的时间，以及基于第一设置时间与第二设置时间的比较以及与第二数据集的使用频率相比较的第一数据集的使用频率来从高速缓存中驱逐数据对象，其中第一数据集被用来构建第一容器，进一步其中第二数据集被用来构建第二容器，且进一步其中该数据对象包括第一数据集。

示例3101包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：测量用于第一容器的第一设置时间，其中第一功能用于在第一容器中执行，测量用于第二容器的第二设置时间，其中第二功能用于在第二容器中执行且第二功能与第一功能不同，以及基于第一设置时间与第二设置时间的比较来从高速缓存中驱逐数据对象，其中该数据对象与第一容器相关联。

示例3102包括示例3101的至少一种计算机可读介质，其中第一设置时间大于第二设置时间。

示例3103包括示例3102的至少一种计算机可读介质，其中第一设置时间是用于配置第一容器的一个或多个名称空间以及第一容器的一个或多个控制组的时间，并且第二设置时间是用于配置第二容器的一个或多个名称空间以及第二容器的一个或多个控制组的时间。

示例3104包括示例3102的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：基于第一容器的使用频率来从高速缓存中驱逐数据对象。

示例3105包括示例3102的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：基于与第二数据集的使用频率相比较的第一数据集的使用频率来从高速缓存中驱逐数据对象，其中第一数据集被用于构建第一容器，其中第二数据集被用于构建第二容器，其中该数据对象包括第一数据集。

示例3106包括示例3102的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：基于第一设置时间来确定第一容器的数据对象的存活时间，以及基于第二设置时间来确定第二容器的数据对象的存活时间。

示例3106包括示例3100的至少一种计算机可读介质，其中该数据对象包括用于发起第一容器的数据。

增强的faas功能分发的示例

如本文已经描述的，一些功能在执行期间可依赖于数据集。各数据集可以被包含在容器中，且因此各功能可以被提供给恰适的容器以访问恰适的数据集。一些数据可能是大的和/或分布式的，诸如在hadoop环境中。由此，将数据集移动到功能可能是低效的和/或增加总环境成本(tce)。即，各个功能可以触碰或修改的数据(例如，它们的存储器或存储或网络印记)可能对于各动作在其中完成的等待时间以及服务提供商所提供的计算资源的高效使用具有显著负担。一些功能和数据集可能在没有专用计算(例如硬件加速器)的情况下增大tce。

由此，在图32a的示例3200中，编排器3202可以分析faas基础设施以标识第一节点3208和第二节点3216中具有用于功能f1的数据集的最低等待时间传递的节点。编排器3202可以基于数据移动以及数据移动成本来调度功能f1。例如，成本分析器3204可以确定功能f1在第一和第二节点3208、3216中的每一者处的总执行成本。总成本可以是数据移动成本和执行成本的加总。总成本可进一步包括等待时间测量、执行时间测量、资源测量、安全信道建立、加密/解密或压缩/解压等待时间测量、网络跳、带宽和缓冲估计等。例如，编排器3202可以确定与功能f1的执行相关联的数据对象以及数据对象的局部性。编排器3202可以基于所偏好的资源利用来编排功能f1和数据对象的分发。由此，编排器3202可以释放资源，降低总执行成本，具有较低的io带宽和较低的等待时间功能执行。

类似于图31a和31b的实施例，第一节点3208包括存储c(1)工作集中的数据对象的高速缓存3212。出于简明起见，对类似组件的类似描述将被略去。例如，图32a的高速缓存控制器3210、高速缓存3212和启动计时器3214可以与图31a的高速缓存控制器3104、高速缓存3102和启动计时器3108类似地操作。同样地，第二节点3216可以与图31a-31b的实施例类似地操作。

如所理解的，c(1)是用于第一容器的缩写。c(1)工作集是用于第一容器的工作集。在该示例中，第一容器已经被拆除并且是不活跃的(未被构建)。当第一容器被拆除时，c(1)工作集被维持在高速缓存3212中以快速构建第一容器。即，c(1)工作集可以被用于构建第一容器。

编排器3202可以确定功能f1是否可以在特定容器中执行。例如，功能分析器3206可以根据功能f1的功能构造来确定可任选字段(例如元数据)的特性。图33a和33b及相关联的描述以更长篇幅讨论功能构造。元数据描述功能f1与数据名称的关联。数据名称可以是数据集构造的身份的近似表示。名称可以通过设置功能(例如，bloom滤波器)和/或名称构造api在功能的各种全局唯一的标识符、功能的调用方、功能的特定参数、与功能相关联的文件系统路径名、例如spark中的弹性分布式数据集谱系、功能访问的关系数据库中的表空间范围等之上来构造。因而，功能分析器3206可以与名称构造api交互以导出名称和/或包括设置功能。在一些实施例中，功能分析器3206可包括名称构造api。更多细节在下文参照图33a和33b来描述。

名称可以是功能f1在执行期间可能需要的资源(例如，加速器、数据、加权公式、硬件要求等)名称的紧凑表示或描述。名称可以指示功能f1在执行期间可以利用特定数据集。此类特定数据集可以被称为f1数据集。

功能分析器3206可以基于元数据来确定名称，并且功能f1可以确定与名称具有软关联的容器的类型以确定该容器是否可包括f1数据集以及在执行期间可能被需要的其他资源中的至少一部分。第一和第二节点3208、3216可以向编排器3202通知任何共享的工作集(例如，c(1)工作集)。编排器3202可以确定c(1)工作集是否可以构建与名称具有软关联的容器。在一些实施例中，编排器3202可以确定c(1)工作集是否包括f1数据集的至少一部分。

因而，编排器3202定义功能f1与数据集之间的关联，其通过将功能f1吸引到具有处理功能f1在执行期间最有可能需要的数据的本地、温暖副本的最高可能性的容器(例如，如下文所描述的第一容器)来用于充当用于引导存储、高速缓存和通信高效的调度的潜在状态。此外，以上增强可以在不违背无服务器抽象的情况下达成。

更详细来说，在当前示例中，功能分析器3206可以确定第一容器包括功能f1在执行期间将利用的f1数据集的至少一部分。编排器3202可以确定第一节点3208包括c(1)工作集，其如上所述可以被用于构建第一容器。由此，编排器3202可以标识第一节点3208可包括f1数据集的至少一部分，并且将功能定向到第一节点3208。例如且在构建之前，编排器3202可以将如存储在高速缓存3212中的c(1)工作集与f1数据集作比较以确定所存储的c(1)工作集包括f1数据集的至少一部分。

作为对比，第二节点3216可能不包括任何相关的数据对象。虽然第二节点3216可包括一些工作集(未例示)，但是那些工作集因为它们不包括与f1数据集的执行相关联的数据而被略去。

成本分析器3204可以确定第一节点3208和第二节点3216执行功能f1的总成本。总成本可以是预估成本、预测估计、预估等待时间和/或估计等待时间，其中预估或估计成本和等待时间要包括在第一和第二节点之间传输数据的成本和等待时间。总成本可进一步包括等待时间测量、执行时间测量、资源测量、安全信道建立、加密/解密或压缩/解压等待时间测量、网络跳、带宽和缓冲估计等。第一节点的总成本3248可以表示用于在第一节点3208处构建容器(例如，第一容器或第一容器的具有添加的数据的修改版本)以及在第一节点3208处执行功能f1的成本。第二节点的总成本3216可表示用于在第二节点3216处构建用于执行功能f1的容器以及在第二节点3216处执行功能f1的成本。总成本可以被比较以确定是要将功能f1发送到第一节点3208还是第二节点3216。

更详细来说，成本分析器3204可以确定第一节点3208和第二节点3216中的每一者用于执行功能f1的总成本。可以确定第一和第二节点3208、3216中的每一者的总成本，并且该总成本可基于通信成本(例如，构建容器需要传递的数据量、与数据的邻近度等)、容器的构建成本、执行等待时间成本(例如，是否需要加速器)等等。

例如，如果来自第一和第二节点3208、3216中的一个节点包括用于促成功能f1的执行的加速器和/或包括用于支持功能f1的足够资源，则可以降低执行等待时间成本。如果缺乏用于支持功能f1的资源或节点不支持加速器，则可能增加执行成本。编排器3202可以基于总成本的比较、或第一和第二节点3208、3216中具有最低总成本的那个节点来将功能f1指派到来自第一和第二节点3208、3216中的一个节点。

例如，第二节点3216可以呈现与第一节点3208相比用于执行功能f1的更高的等待时间(例如，更高的等待时间成本)。详细来说，第二节点3216可能需要接收用于构建用于功能f1的容器的全部数据并且接着构建该容器。作为对比，第一节点3208可以从在本地存储在高速缓存3212中的c(1)工作集快速地构建第一容器，并且在需要时用进一步的数据来修改第一容器，以藉此避免第二节点3216所呈现的至少一些通信等待时间成本。因而，由于f1数据集与c(1)工作集之间的交叠，第一节点3208的通信等待时间相对于第二节点3216可以被减少，藉此降低第一节点3208的总成本。结果，在第一节点3208处执行功能f1的总成本可低于在第二节点3216处执行功能f1的总成本。

在一些实施例中，c(1)工作集可仅包括f1数据集的一部分，数据的剩余部分在第一容器构造之前或在第一容器的构造期间抵达第一节点3208。在此类实施例中，成本分析器3204可将传递数据的剩余部分的成本作为在第一节点3208处执行功能f1的总成本的一部分来包括。在第一节点3208接收到数据的剩余部分之后，第一容器可以用该数据的剩余部分被扩充以执行功能f1。

在当前示例中，编排器3202可以确定功能f1在第一节点3208处执行的总成本低于功能f1在第二节点3216处执行的总成本。过程3224可以分发功能f1。详细来说，编排器可以将功能f1提供给第一节点3208。如图32b中所例示的，第一节点3208在第一节点3208中构建容器c(1)3226(例如，第一容器)，且基于存储在高速缓存3212中的c(1)工作集。

在一些实施例中，容器c(1)可以用未被包括在c(1)工作集中的进一步的数据来扩充以促成功能f1的执行。功能f1接着可以开始执行。例如，第一节点3208可以接收功能f1在执行期间利用的一些数据，并且可以在容器c(1)的构建期间将该数据添加到容器c(1)。

转向图32c，例示了示例3240。出于简明起见，与图32a、32b中所例示的组件类似的组件在此处将不再赘述。然而将理解，对应的组件可以彼此类似地操作。

在示例3240中，功能f2要由编排器3242来指派。类似于以上实施例，第一节点3248包括用于构建用于执行功能f2的第一容器的c(1)工作集，而第二节点3258不包括此类工作集。

功能分析器3246可以分析功能f2以确定f2数据集。编排器3242可以确定c(1)工作集仅包括f2数据集的第一部分。由此，f2数据集的第二部分必须被传送到第一节点3248以便在第一节点3248处执行功能f2。第二节点3258可能不包括任何相关的工作集，并且因此需要在第二节点3258处构建用于执行功能f2的新容器。

成本分析器3244可以确定第一节点3248和第二节点3258的总成本。第一节点3248的总成本可包括用于将f2数据集的第二部分传送到第一节点3248的成本。第一节点3248与要将f2数据集的第二部分传送到第一节点3248的数据源相距很远。该数据源可以是另一节点，且可以是离第一节点3248最近的具有f2数据集的第二部分的节点。成本分析器3244因此可以确定用于传送f2数据集的第二部分的通信成本是高的，且第一节点3248的总成本是相应地高的。

第二节点3258的总成本可以是用于接收用于构建第一容器的全部构建数据的成本。然而，在该当前示例中，第二节点3258可以位于数据源附近。该数据源可包括全部的构建数据，并且可以能够将该构建数据传送到第二节点3258。由此，第二节点3258的通信成本可以显著低于第一节点3248的通信成本。由于通信成本之间的显著差异，第二节点3258可具有较低的总成本，即便不存在任何工作集。即，编排器3242可以确定由于第二节点3258的较低的数据传递成本在第二节点3258处执行功能f2是更高效的(更低的等待时间)，尽管第二节点3258不具有工作集。因而，编排器3242可以在更靠近数据源的节点处构建容器而非在远离数据源的节点(即便其具有相关的工作集)处构建容器以降低等待时间成本。

在过程3266中，编排器3242可以分发功能f2。如在作为图32c的示例3240的延续的图32d中所例示的，功能f2被提供到第二节点3258。容器3268可以被构建以执行功能f2且其可以基于从数据源接收的数据。

因而，图32a-32d的以上实施例可以以增强的方式将计算推向数据来执行各个动作，这些动作原本不知悉它们在其上运行的硬件或不知悉在它们执行期间它们可能引用的数据的物理位置。各实施例可以减少执行功能的等待时间并且进一步减少资源利用。

图32e示出了增强的功能分发方法3280，且可以在图32a-32d的增强的faas服务器架构和/或一个或多个模块中被实现为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法3280中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框3282可以标识要被执行的功能。所例示的处理框3284可以确定功能在执行期间将利用的数据集。所例示的处理框3286可以确定第一工作集是否包括该数据集的至少一部分。第一工作集可包括用于启动第一容器的资源。此外，第一工作集可以被存储在第一节点处。例如，第一工作集可以被存储在第一节点的硬件和/或软件高速缓存中。

所例示的处理框3288可以计算用于在第一节点处执行第一功能的第一总成本。第一总成本计算可基于第一工作集是否包括该数据集的一部分。作为示例，所例示的处理框3286可以确定第一工作集仅包括该数据集的第一部分。在此类实施例中，所例示的处理框3288可以确定用于将该数据集的第二部分传递到第一节点的传递成本(其可以被称为第一总传递成本)，并将该传递成本包括在第一总成本中。例如，所例示的处理框3288可以确定第一总成本包括用于构建第一容器的成本和传递成本。

所例示的处理框3290可以计算用于在第二节点中的第二容器处执行第一功能的第二总成本。第二总成本可包括用于传递数据以在第二节点处构建第二容器的数据传递成本，以及用于构建第二容器的成本。第二容器可以是冷容器。

所例示的处理框3292可以基于第一和第二总成本的计算来确定是要在第一节点处还是在第二节点处执行该功能。作为示例，所例示的处理框3292可以基于第一工作集是否包括该数据集的至少一部分来确定是否要在第一节点处启动第一容器并在第一节点处的第一容器中执行该功能。

所例示的处理框3292可以在第一总成本低于第二总成本时在第一节点处构建第一容器并且在第一节点处的第一容器中执行该功能。作为对比，在第二总成本低于第一总成本时，可以在第二节点处构建第二容器，并且该功能可以在第二节点处的第二容器中执行。

附加注解与示例

示例3200包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：标识要被执行的功能，确定该功能在执行期间将利用的数据集，确定第一工作集仅包括该数据集的至少第一部分，其中第一工作集包括用于启动第一容器的资源，其中第一工作集被存储在第一节点处，其中第一工作集被存储在第一节点的高速缓存中，确定用于将该数据集的第二部分传递到第一节点的传递成本，确定用于在第一节点处执行该功能的第一总成本，其中第一总成本包括用于构建第一容器的成本和传递成本，确定用于在第二节点处的第二容器中执行该功能的第二总成本，其中第二总成本包括用于传递数据以在第二节点处构建第二容器的数据传递成本以及用于构建第二容器的成本，在第二总成本低于第一总成本时在第二节点处构建第二容器并且在第二节点处的第二容器中执行该功能，以及在第一总成本低于第二总成本时在第一节点处构建第一容器并在第一节点处的第一容器中执行该功能。

示例3201包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：标识要被执行的功能，确定该功能在执行期间将利用的数据集，确定第一工作集是否包括该数据集的至少一部分，其中第一工作集包括用于启动第一容器的资源，其中第一工作集被存储在第一节点处，以及基于第一工作集是否包括该数据集的至少一部分来确定是否要启动第一节点处的第一容器以在第一节点处的第一容器中执行该功能。

示例3202包括示例3201的至少一种计算机可读介质，其中第一工作集被存储在第一节点的高速缓存中。

示例3203包括示例3201的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定第一工作集仅包括该数据集的第一部分，以及确定用于将该数据集的第二部分传递到第一节点的传递成本。

示例3204包括示例3203的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：确定用于在第一节点处执行该功能的第一总成本，其中第一总成本包括用于构建第一容器的成本和传递成本，确定用于在第二节点处的第二容器中执行该功能的第二总成本，其中第二总成本包括用于传递数据以在第二节点处构建第二容器的数据传递成本以及用于构建第二容器的成本。

示例3205包括示例3204的至少一种计算机可读介质，其中第二容器是冷容器。

示例3206包括示例3204的至少一种计算机可读介质，其包括进一步的一组指令，该指令在由计算设备执行时致使该计算设备：在第二总成本低于第一总成本时在第二节点处构建第二容器并且在第二节点处的第二容器中执行该功能，以及在第一总成本低于第二总成本时在第一节点处构建第一容器并在第一节点处的第一容器中执行该功能。

增强的faas功能构造的示例

图33a例示了功能的功能构造3300。如参照图32a-32d的实施例所讨论的，功能构造300可以被用于确定用于执行功能的合适的模式。在图33a中，功能构造3300包括描述与数据名称的关联的可任选字段。功能构造字段可以被读取以标识其中包含的元数据，并且基于该元数据作出与名称的关联。数据名称可以是功能构造3300的身份的近似表示。名称可以通过设置函数(例如，bloom滤波器)和/或名称构造api在功能的各种全局唯一的标识符、功能的调用方、功能的特定参数、与功能相关联的文件系统路径名、例如spark中的弹性分布式数据集谱系、功能访问的关系数据库中的表空间范围等之上从功能构造3300来构造。通过功能构造3300来定属性的功能可以被提供以供在与从功能构造中导出的那些名称具有软关联的容器处执行。因而，各个名称可以被用于有效地指派功能以减少资源和等待时间。

数据集构造包括若干字段。各字段的属性可以在功能创建时被生成以及基于功能执行和高速缓存/存储器颠簸的水平被动态地更新。基于功能执行期间所触碰的数据，从功能构造3300收集的数据，与功能构造3300相关联的功能可以被指派到可能拥有数据的温暖副本的容器，藉此减少数据移动并减少颠簸的可能性。

调用方字段3302可以被用于标识功能调用的源(例如，客户端、计算设备、地理区域等)。调用方名称可以从调用方字段3302中确定以描述源的身份、位置和/或设备。

自变量字段3304可以被用于标识功能的自变量。自变量可以被用于确定功能的类型、底层数据要求等。例如，进入自变量的输入数据可以被标识、对特定语言库的访问和/或数据要求可以被标识。此外，某些类型的自变量可以通过特定硬件利用来增强。由此，类型名称可以从自变量字段3304中确定以描述功能的计算机语言、数据要求(例如，加速器、存储器空间、处理器速度)、硬件要求等。

其他字段3306可以被用于标识功能的其他属性。例如，其他字段3306可以被用于标识用于执行的地理位置、客户端的位置等。另一名称可以从其他字段3306中确定以描述地理位置和客户端的位置等。该另一名称可以被用于将功能定向到靠近客户端的地理位置或数据最终将被传送到的位置的节点。

文件系统路径3308可以被用于确定功能的路径。例如，文件系统路径3308可以被用于标识要保存功能的输出的位置。路径名称可以从文件系统路径3308中确定以描述要保存输出的位置。路径名称可以被用于将功能定向到靠近保存输出的位置的节点。

数据库表空间范围3310可以被用于描述出于紧凑标识和与功能的数据集相关联的后续使用的目的数据库中一组“元组”的逻辑身份。范围名称可以从数据库表空间范围3310中确定以描述数据的逻辑范围，这些数据在各个字段中的值或属性落在范围最小和范围最大值内。它可以基于数据内各字段所满足的各约束被用来紧凑地描述在功能中使用的数据的范围。

图33b示出了从增强的功能构造(如图33b所示)的名称标识方法3350，且可以在图32a-32d的增强的编排器3202、3242和/或一个或多个模块中被实现为存储在诸如ram、rom、prom、固件、闪存等机器可读或计算机可读存储介质中的一组逻辑指令，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能逻辑硬件中，或被实现为以上任何组合。

例如，可以用一种或多种编程语言的任何组合来编写用于实施在方法3350中所示的操作的计算机程序代码，这些编程语言包括诸如java、smalltalk、c++等的面向对象的编程语言以及诸如“c”编程语言或类似编程语言的常规的过程编程语言。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

所例示的处理框3352可以标识与功能相关联的功能构造的字段。所例示的处理框3354可以确定来自字段的元数据。

所例示的处理框3356可以确定来自字段的一个或多个名称，其中名称用于指示该功能在执行期间要利用的一个或多个资源。例如，该一个或多个资源可包括该功能在执行期间要利用的数据。该一个或多个资源可进一步包括该功能的硬件资源要求。该一个或多个资源可进一步包括该功能在执行期间要利用的硬件加速器。此外，该一个或多个名称可以指示用于执行该功能的地理位置。此外，该一个或多个名称可以指示该功能的类型(如，图像识别或图像旋转)。如上所述，该一个或多个资源和该功能的类型可以被用于将该功能分配到恰适的节点，并在增加效率的同时降低等待时间。

附加注解与示例

示例3300包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：标识与功能相关联的功能构造的字段，以及确定来自字段的元数据，确定来自该元数据的一个或多个名称，其中该名称用于指示该功能在执行期间要利用的一个或多个资源，其中该一个或多个资源包括该功能在执行期间要利用的数据、该功能的硬件资源要求、该功能在执行期间要利用的硬件加速器，其中该一个或多个名称指示用于执行该功能的地理位置和该功能的类型。

示例3301包括至少一种计算机可读介质，其包括一组指令，该指令在由计算设备执行时致使该计算设备：标识与功能相关联的功能构造的字段，以及确定来自字段的元数据，以及确定来自该元数据的一个或多个名称，其中该名称用于指示该功能在执行期间要利用的一个或多个资源。

示例3302包括示例3301的至少一种计算机可读介质，其中该一个或多个资源包括该功能在执行期间要利用的数据。

示例3303包括示例3301的至少一种计算机可读介质，其中该一个或多个资源包括该功能的硬件资源要求。

示例3304包括示例3301的至少一种计算机可读介质，其中该一个或多个资源包括该功能在执行期间要利用的硬件加速器。

示例3305包括示例3301的至少一种计算机可读介质，其中该一个或多个名称指示用于执行该功能的地理区域。

示例3306包括示例3301的至少一种计算机可读介质，其中该一个或多个名称用于指示该功能的类型。

动态放置和预取示例

对于当前存在的解决方案，faas功能在功能执行的每一阶段并非被最优地放置。例如，在执行的场可编程门阵列(fpga)版本与软件(存储器)版本之间可能存在回流数据的高资源成本。通常，基础设施可能无法在任何给定时间具有足够的存储器来保持期望数目(和类型)的功能容器以供快速重用。

现在转向图34a，根据示例性实施例，示出了示例，其中使用调用图以基于功能调用的频率来预取功能。用户接口处置器3440可以接收要优化faas功能执行的请求3450并进而生成调用图3460。调用图3460可以表示各功能之间的调用关系3462。

在所例示的示例中，编排器3470可以基于调用图3460中所指示的功能调用频率来预取接下来最有可能被调用的功能3480。被预取的功能可以被加载到临时存储中并被初始化。在所例示的示例中，被预取的功能可以被临时地存储在服务器3490的高速缓存3492中。编排器3470可以向服务器3490发出命令以释放最不可能被调用的功能。

图34b例示了根据实施例的用于增强执行faas功能的方法。在方法3400的框3410，可以生成指示功能激活(“调用”)的频率的调用图。调用图可以是表示各功能之间的调用关系的控制流图。在加权调用图中，每一弧线(源自前驱(在先功能)且结束于一个或多个后继者功能)可以用后继者调用的频率(例如，前驱会导致该后继者的概率)来加标签。调用图可以类似于控制流图，区别之处在于控制流图在各过程之间具有调用返回关系(和嵌套)，而用于功能的调用图是正在执行的各个功能以及逐步触发致使其他功能的执行的条件的图形指示，通常在后的功能消耗或访问由在前的功能产生的数据或结果。根据示例性实施例，了解当前功能f正在执行并且它将导致功能g执行的情况意味着g可以被“预取”——其构造可以开始，其数据可以被放置/映射等。调用图上的权重可以表示概率——指示f会导致g的执行的可能性。

调用图可以被静态地形成，且接着可以被动态地细化。在框3420，基于调用图中所指示的功能调用频率，接下来最有可能被调用的功能可以被预取。即，被预取的功能可以被加载到临时存储中并被初始化，以使得该功能在前驱功能激活它时已准备好被执行。在框3430，在调用图的每一阶段/区域最不可能被调用的faas功能可以被卸载以释放资源。

与常规程序中的正常过程调用序列类似，一个“调用方”功能可以可任选地直接通过远程过程调用来调用另一“被调用方”功能(并接着等待接收对被调用方的该远程过程调用已完成的指示)。上述弧线可以由与后继者功能的执行相关联的成本来被进一步扩充，对于faas而言，该成本可包括传递参数和结果的成本。例如，javascript对象符号(json)对象的开销可以被传递，考虑到主存被调用方和调用方函数的两个点之间的比特大小和通信带宽。基于调用频率、每一主机上的可用资源、调用开销、所提供的定价/优先级层等，可以在每一阶段计算faas功能的最优放置。各个阶段可以是动态的。即，每一次某一功能f被激活，功能f的激活可能导致某一其他功能g的激活，而一般地g可以在不同的地方被执行。

方法3400的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法3400的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法3400可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法3400的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例3401包括一种方法，其包括：形成表示功能之间的调用关系的调用图，该调用图指示前驱到后继者激活的频率或可能性，基于调用图所指示的功能调用的频率预取最有可能的下一个功能以使得最有可能的下一个功能在被调用时已经准备好运行，以及卸载至少一个最不可能的下一个功能。

示例3402包括示例3401的方法，进一步包括：该调用图利用表示调用被调用频率的弧线。

示例3403包括示例3402的方法，进一步包括基于功能调用的所述频率/概率来计算每一主机上的可用资源。

示例3404。示例3401的方法，其中功能调用用于向下兼容到现有应用。

示例3405。示例3401的方法，其中存储完整性协议要被用于标识存储器中的数据版本。

示例3406包括一种方法，其包括：形成表示功能之间的调用关系的调用图，该调用图指示功能调用的频率，基于调用图所指示的功能调用的频率预取最有可能的下一个功能以使得最有可能的下一个功能在被调用时已经准备好运行，卸载至少一个最不可能的下一个功能，利用调用图中的弧线，该弧线表示调用被调用的频率，以及基于功能调用的频率来计算每一主机上的可用资源，其中该功能调用用于向下兼容到现有应用，且其中存储器完整性协议要被用来标识存储器中的数据版本。

多租户功能的渐进式多版本初始化的示例

在紧接着的上文中描述的示例性实施例可以在在先历史的基础上(例如，不仅仅基于第二功能本身而是基于其前驱链的子集)被延伸到功能链c：{f(i)…f(ii)…f(iii)…f(n)}中的第二功能b。换言之，在选择是否要启动基于软件的、最小加速的、或加速版本的功能，示例性实施例可以不仅将功能b的使用历史纳入考虑，还将该链中在b之前的前驱功能bp的使用历史纳入考虑。图35a是示出功能b3560的前驱功能bp3550可以被用于确定要被预取和调用的下一功能的框图，其中功能3560的前驱功能bp3550当前正被执行。

该实施例的示例性益处包括同时均衡(多个争用者之间的)有限加速资源的使用以及最小化在执行的硬件(例如，fpga)版本与软件(存储器)版本之间回流数据的成本。在实践中，该实施例可以实现激活最小版本的加速功能的链而非激活全部版本，以使得数据回流被最小化。

根据示例性实施例，可能存在深度为1的链：bp→b，其中bp表示在功能b之前的功能，如上所说明的。

根据该实施例，功能bp是功能b的紧接着的前驱，而x和y可以分别是功能b的完整版本的启动阈值和回收阈值。类似地，u和v可以分别是bp的完整版本的启动阈值和回收阈值。在功能的存活时间期满的情况下或者在其他考量(诸如用于被保持运行的其加权测量)已经落在某一阈值之下的情况下，功能的资源被“回收”。在相反方向上，相对于启动阈值，如果通常未被高速缓存或预取的功能正显示出增加使用的迹象，则通过该增加使用，它变得有吸引力以使该功能高速缓存并可能地被预取。因而，根据示例性实施例，如果功能的前驱功能当前正在运行且具有增加的频率，则前驱功能可致使功能b被预取的资格超过启动阈值。根据示例性实施例，用于相应功能的回收阈值可低于启动阈值。

同样，在u被降低时，x可以被降低一小的量z(耦合贡献)，且在v被增大时y可以被增大一小的量z，以致力于确保期望的硬件或软件条件被满足。此类修改符合x、y和|x–y|都受到约束以取不违反各个最大/最小规则的值的条件。

根据另一示例性实施例，如果u和v不被允许改变但x和y可以改变，则虚拟值u’和v’(u和v的阴影值)可以被计算，并且接着分别基于所计算的值u’和v’，耦合贡献z可以被应用于x和y。根据示例性实施例，例如值‘u’和‘v’可能不被准许改变，因为要使bp的资源利用保持受控制的需要；然而，如果在进入bp的抵达率方面存在上涨，则该上涨可能影响x使其向下(由于进入b的抵达率会增大)且类似地y会受到影响而向上(以降低针对b的回收率)。

上述实施例可以被传递地推广到链深度>1。一般来说，在计算耦合贡献(z)方面存在多于一个的参数，例如，在资源受约束的环境中，在对功能b及其前驱的需求下降(以使得b可能更快速地被回收)时，可以对于给定的加速功能b施加存活时间方面的可变量的增加；类似地，在整体需求较低或在sla要求严苛时，基于在其前驱处的观察，可能存在针对启动功能b的更强的正面偏向以及反对回收b的更强的反面偏向。

现在转向图35b，根据示例性实施例，在方法3500的框3510中，功能a可以被启动。在框3520，在功能a之前的前驱功能b可以被标识。在框3540，基于前驱功能b以及功能a的使用历史可以确定是否要启动功能a的加速版本。

方法3500的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法3500的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法3500可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法3500的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例3501包括一种方法，其包括：启动功能，标识在该功能之前的前驱功能，基于在该功能之前的前驱功能以及该功能的使用历史来确定是否要启动该功能的加速版本，以及将该功能和前驱功能存储在储存库中。

示例3502包括示例3501的方法，进一步包括使用消息认证码(mac)来标识存储器中的功能版本。

示例3503包括示例3501的方法，进一步包括容器拦截远程过程调用(rpc)并在本地服务该rpc，其中该功能要对现有应用是透明的且向下兼容到现有应用。

示例3503包括示例3501的方法，进一步包括预取与该功能有关的数据。

示例3504包括一种方法，其包括：启动功能，标识在该功能之前的前驱功能，基于在该功能之前的前驱功能以及该功能的使用历史来确定是否要启动该功能的加速版本，使用消息认证码(mac)来标识存储器中的功能版本，经由容器来拦截远程过程调用(rpc)并在本地服务该rpc，其中该功能要对现有应用是透明的且要向下兼容到现有应用，预取与该功能有关的数据，以及将该功能和前驱功能存储在储存库中。

自适应回收率示例

现在转向图36a，根据另一示例性实施例，图36a示出了基于功能正被执行的概率维持容器的温暖度的示例。详细来说，在容器3650中完成(执行)功能x3655之际，存在另一功能y3675将在容器3670中被执行的概率p3660。例如，在视频监控应用中，功能x3655可以是媒体转码功能而功能y3675可以是检测和粗粒度匹配功能(例如，用于确定视频流是否示出了一个人或一个人的一部分的功能)；或者功能x3655可以是粗粒度匹配功能而功能y3675可以是识别功能(例如，用于确定在视频中检测到的任何人是否同样还是数据库中的已知人(例如，朋友或家庭成员)、陌生人等的功能)。这一概率p3660可以是常量，但通常是基于处理时间以及其他时间上或空间上相关的因子而可变的。

编排器3680的概率评估器3685可以生成使用于功能y3675的容器3670保持温暖的决策，这可依赖于这样的概率p3660的动态评估；或者更一般地，功能类型y的容器回收率可以根据这一概率p3660而变化。通过基于概率p3660的最近和历史评估两者来适配回收率和决策，可以达成对最近信息作出适配且同样相对于长期信息进行负载均衡的总目标。

在紧接着的上文中的示例性解决方案可以被推广到功能调用的图或服务网格，且可以被进一步推广到加速功能，以使得仅(i)回收时间是自适应地变化的，但(ii)对概率的更长期的评估跨多个图边缘流动，可以被用于预激活其激活时间(热身)时间并非微不足道的那些功能。

在一个实施例中，概率图模型(pgm)可以被用作用于对一个或多个相互依赖的功能的概率流进行因子化的通用框架。pgm因子化技术和库可以被用于获得每一功能y3675的基于其对其前驱功能x3655的依赖性的动态概率，以及功能x3655的基于功能x的3655的前驱的动态概率。更简单的但可行的简化可以是移除弱概率流(例如，将弱相关的功能作为相互独立来对待)，以使得此类图是稀疏的，并且接着应用用概率编程语言(例如figaro)编写的pgm求解器。另一实现可以是使用搜索页排名方案作为将功能的受欢迎程度按照某一权重(其本身可以提前被估计或被动态推断)与其前驱或先驱的受欢迎程度进行关联的简化形式，并且使用迭代页排名解决方案来基于可用数据来估计不同功能有可能有多频繁地被执行。

此类办法可以允许对功能的加速或传统(基于cpu软件的)实现两者的灵活资源分配，而非使用硬编码的常量或简单试探法来控制温暖容器的数目或存活时间(ttl)参数。替换地，该示例性实施例可以用于其他实现，并且可以被用于基于所收集的遥测的周期性评估使用以上的概率流技术调整对容器数目或其ttl的此类配置设置。此外，总优化问题本身可具有箱式打包问题，其试图通过最大化较高概率激活的吞吐量(按其资源要求被标准化)来使资源受约束的吞吐量最大化。

现在转向图36b，例示了根据实施例的用于从温暖容器执行faas功能的方法。在方法3600的框3610中，功能a可以被启动。在框3630中，基于功能a的后续功能将被执行的概率的动态评估来维持用于执行该后续功能的计算容器的准备就绪(例如温暖度)。

方法3600的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法3600的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法3600可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法3600的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例3601包括一种方法，其包括：执行功能，在执行该功能之后，基于后续功能将被执行的概率的动态评估来维持用于执行该后续功能的容器的准备就绪。

示例3602包括一种方法，其包括：执行功能，在执行该功能之后，基于后续功能将被执行的概率的动态评估来维持用于执行该后续功能的容器的准备就绪，仅清除功能数据但不清除功能逻辑，在单独密钥被指派给单独功能时确定多密钥完全存储器加密(mktme)密钥，以及仅回收用户程序但不回收托管运行时。

自适应存储器分层示例

在功能变得较少被使用时，它所占据的容量的量可以被减少。通常，基础设施可能无法在任何给定时间具有足够的存储器来保持期望数目(和类型)的功能容器以供快速重用。

根据诸如图4中示出的增强的faas系统之类的增强的faas系统的示例性实施例，在决定功能是否应当使其数据或代码在高性能存储器层中时可以考虑功能的大小和使用频率两者。在其他实施例中，这可以基于使用：使不太使用的功能在较低性能的层(如3dxp存储器)中保持存活而非将其全部回收。根据具有存储器分层的增强的faas系统的一个实施例，可以使存储器中的分层对大小和使用两者进行适配。即，如果大小是大的，则即便功能被频繁使用，该功能也可以被放置在远离层(如3dxp)中。如果使用较低，则同样该功能可以被放置在远离层中。此外，如果功能在较远的层中，则它应当被提供相应地更长的存活时间，因为它已经在消耗较少的资源。

在其他实施例中，已经描述了对存储器的多个、实际或虚拟化层的使用以达成整体较高的温暖容器率而不过度订阅性能关键的存储器容量(诸如mcdram/hbm或ddr层中)。在图37a所示的当前示例性实施例中，相同的办法可以被应用于功能内以及被应用于功能链。

1.功能内：首先，考虑功能与多层存储器中的性能层(例如，mcdram/hbm、dram)中的可用容量的量相比可能常常是过大的(例如，亚马逊lambda对每一容器施加约400mb的限制，这对于许多拓扑结构的公共版本而言是足够大的，但是对于用于深度神经学习网络的数学核库(mkl-dnn)而言可能过小)。

根据当前的示例性实施例，该示例性实施例的各方面在图37a和37b中例示，各功能可以根据大小以及根据使用被分段，以使得：

1a.过大而无法被指派dram放置的功能3710可以被预指派到外部存储器层3720中(图37a)；以及

1b.具有整体高历史使用频率但已经超出其当前暂停率阈值的功能可以被延迟保持在外部存储器层中而非被立即回收；且它们可以在那里老化达一较长的历时。暂停率阈值实际上可以是功能容器在其最近使用之后的存活时间。如果在该时间内没有请求抵达，则该功能可以被移除，以使得其资源(主要是存储器)被释放。

根据随着时间的使用统计数据和存储器页访问概况分析，较热的页集可以被反映进入mcdram/hbm/ddr保留的范围中，除非功能的动态代码印记恰好过大而无法获益于使其一部分被临时指派到性能层中。

2.跨功能链：在紧接着的上文中描述的各实施例可以被延伸到功能链，从而：

2a.如图37b中所例示的，如果功能链(或功能网)中的功能x(i)3740的先驱功能3730或依赖功能3750是活跃的，无论被指派在上半部分还是下半部分的存储器层中，则代替回收x(i)(例如，拆除主存x(i)的容器)，x(i)可以基于那些前驱和/或依赖功能的继续而被给予外部层放置。

这一自适应存储器分层办法可以被实现，因为相比于其存储器在存储器的外部层中的非冷容器的较慢性能，执行的等待时间对冷容器要敏感的多。此外，在近层中具有足够的空闲容量时，这一办法不会排除临时促进此类活跃容器被维持在远层中。

图37a的创造性概念可以被应用于功能内的不同对象。在示例性实施例中，软件可以知晓更多关于功能打算保留功能数据的什么部分以及不保留功能数据的什么部分。因此，对于可能通常被分配在例如java苗圃(nursery)(年轻对象区域)中的对象，如果已知该对象有可能被使用较长的历时，则该对象可以被分配到其他位置，例如，在存储器的性能不太高的层中。即，代替将大功能的整个功能主体放置在外部层中，大功能的非苗圃部分可以被放置在外部层中，因为苗圃存储器可以以任何方式被快速回收。

根据示例性实施例，可能存在这样的情形，其中图37a或37b中示出的外部层可能不受针对隐私攻击的保护，因为例如它不受硬件密钥机制的保护。因此在该情形中，解决方案可以是使功能的主体保持在由软件加密的外部层中，接着在该功能需要被激活时对其解密，并将该功能主体放置在被硬件保护覆盖的存储器层中。对于此类加密-解密，密钥可以与功能相关联，其中密钥在受硬件保护的存储器中被保护，并且该密钥可以在基于软件的加密解密方法中使用。解密功能主体和状态与从零开始重构功能相比可能成本更低，尤其在功能大小较大的情况下。

现在转向图37c，例示了根据实施例的用于自适应地对功能进行存储器分层的方法。在方法3700的框3710中，功能a可以被启动。在框3720中，确定功能a的大小和使用频率。在框3730中，确定功能a是否被频繁使用。如果在框3730中确定功能a被频繁使用，则在框3740中确定功能a的大小是否是大的。如果功能a的大小是大的，则在框3750，功能a被放置在存储器的远层中。

方法3700的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法3700的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法3700可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法3700的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例3701包括一种方法，其包括：执行功能，确定该功能的大小和使用频率，以及在功能被频繁使用且大小是大的情况下，将该功能放置在存储器的远层中。

示例3702包括示例3701的方法，进一步包括使用加密技术在存储器分层结构中移动功能。

示例3703包括示例3701的方法，使用高速缓存在功能之间进行通信。

示例3704包括一种方法，其包括：执行功能，确定该功能的大小和使用频率，在功能被频繁使用且大小是大的情况下，将该功能放置在存储器的远层中，使用加密技术在存储器分层结构中移动功能，以及使用高速缓存在功能之间进行通信。

快速类加载示例

csp通常可以利用用于faas的灵活调度机制/模块。加载和拆除用于faas的托管运行时容器可能是成本较高的，由此，可能消耗可被用于其他目的(例如，处理活跃功能、分发和调度新功能、任何其他类型的生成收益的目的等)的珍贵的cpu时间。因而，加载和拆除容器可能降低效率并增加功率使用。这一问题对于静态类型的托管运行时语言(诸如java)可能尤其严重，因为托管运行时系统(诸如举例来说java虚拟机(jvm))可能需要加载完整的基本类库集来运行例如简单的“你好世界”程序。这对于常规的数据中心使用而言可能不是问题，但是对于faas而言却是成本高昂的。

与长时间运行的应用或连续的微服务不同，对faas执行的请求的自组织、猝发性、和非预期的抵达率使得达成qos预期是困难的，尤其在qos预期本身逐个功能变化的情况下。

根据示例性实施例，如图38a的框图中所例示的，提供了基于工作负载的类加载优化模块，其中仅被使用的类被优化类加载器加载。该模块实现快速的托管运行时加载时间。

在图38a中，类使用数据3860可以经由定制托管运行时系统类加载器3850(例如，定制java虚拟机)来获得，其中：定制托管运行时系统类加载器3850的分析器3854在faas服务的功能的第一执行期间可以被调用。在一些实施例中，分析器3854可以在第一执行之后发生的该功能的执行期间被调用。诸如类依赖性图、类、方法和可变初始化、偏移计算、去虚拟化、以及与将jni功能绑定到java原生方法的数据之类的使用数据可以被保存为用于云功能的稍后调用的元数据文件。工作负载输入3862可包括用于faas功能的输入和/或值。

-定制托管运行时系统类加载器3850可以经由元数据文件加载器3856来加载与特定faas功能相关联的、用于该功能的所有后续执行的元数据文件。

-由于包括来自类使用数据3860、工作负载输入3862(例如，用于该特定faas功能的输入)、以及faas机器学习框架3870的数据的不同的数据源，可以建立用于单个faas功能的多个元数据文件。由faas机器学习框架3870生成的机器学习算法和/或方案可以被用于对定制托管运行时系统类加载器3850的进一步增强以如上所述地降低和/或消除低效。这些增强(例如，加速器使用、特定代码使用、用于执行的定时等)可以被提供给定制托管资源系统类加载器3850并且被存储为元数据文件加载器3856。此外，faas机器学习框架3870可以基于对功能的这些增强是否成功来被修改。例如，这些增强可包括对功能的将来执行的修改。如果这些修改以某种方式提高了效率(降低了功率、降低了等待时间、降低了资源使用等)，则这些修改可以被认为是成功的，并且faas机器学习框架3870可以将类似的这样的修改尝试用于该功能以及其他功能的将来调用。如果这些修改是不成功的，则faas机器学习框架3870可以回滚这些修改并且不将这些修改应用于其他功能。

根据示例性实施例，faas机器学习框架3870可以促成从功能历史中开发的按时间排序的反馈以及从并发且独立发生的大量功能激活中吸收的云规模反馈两者的持续应用。以此方式，这是某种形式的持续学习与群体学习的组合。faas机器学习框架3870可以基于实际类使用数据3860、工作负载输入3862、以及来自元数据文件加载器3856的元数据以及来自分析器3854的数据来训练。

现在转向图38b，根据示例性实施例，在方法3800的框3810中，可以在faas服务的功能的初始执行期间调用分析器功能。在框3820中，使用数据可以被存储为元数据文件以供该功能的后续执行。在框3840中，元数据文件可以被加载以供该功能的后续调用。

方法3800的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法3800的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法3800可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法3800的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

现在转向图38c，根据示例性实施例，在方法3850的框3852中，可以在faas服务的功能的初始执行期间调用分析器功能。在框3854中，可以训练机器学习框架。在一些实施例中，机器学习框架可以基于由定制托管运行时系统类加载器存储的元数据、与该功能相关联的类使用数据和工作负载输入来训练。

在一些实施例中，faas提供商可能要求开发人员将特定运行时系统和/或库包括在faas部署包中，该特定运行时系统和/或库可以是定制制作的和/或与用于给定语言和/或运行时的标准库和运行时系统不同。在一些实施例中，建议的运行时系统和/或库可以由faas提供商或第三方提供。在一些实施例中，定制运行时系统可以将关于功能的执行特性的附加信息提供给开发人员或用户(例如，关于代码执行特性的简档信息，诸如执行时间、被执行语句的计数、代码覆盖、功率/能量消耗、被分配的存储器的量、发生异常的数目，或关于与代码执行相关联的微架构事件的遥测数据，包括误预测分支指令的数目、os页错误、以及数据/指令高速缓存未命中等)。在一些实施例中，定制运行时的使用可能导致与标准运行时相比更短或更长的执行时间。具体地，在智能定制运行时系统中，相同代码的执行可能随着时间随着智能运行时学习关于该功能的典型行为而改进，并且可使用预处理和/或预期技术(诸如猜测和校验)以实现更快的性能。在此类实施例中，执行相同代码的成本随着时间可能越来越便宜，并且这一改变能够由开发人员或用户通过运行时和/或库的定制的使用来观察到。因而，智能运行时可以定制功能的执行环境。

方法3850的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法3850的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法3800可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法3850的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例3801包括一种方法，其包括：在faas服务的功能的初始执行期间调用分析器功能，将使用数据存储为元数据文件以供该功能的后续调用，以及加载该元数据文件以供该功能的后续调用，其中多个元数据文件对应于单个功能。

示例3802包括根据示例3801的方法，进一步包括基于执行环境来回收该功能。

示例3803包括根据示例3802的方法，进一步包括在该执行环境中实现安全策略。

示例3804包括根据示例3801的方法，其中一些功能集用于用相同的mktme密钥来编码。

示例3805包括一种方法，其包括：在faas服务的功能的初始执行期间调用分析器功能，将使用数据存储为元数据文件以供该功能的后续调用，加载该元数据文件以供该功能的后续调用，基于执行环境来回收该功能，以及在该执行环境中实现安全策略，其中多个元数据文件对应于单个功能，并且其中一些功能集用于用相同的mktme密钥来编码。

功能资源利用示例

对于faas激活而言关键的挑战之一是在使效率最大化并广泛改变符合qos的执行的同时的灵活资源均衡。与长时间运行的应用或连续的微服务不同，对faas执行的请求的自主式、猝发性、和非预期的达到率使得达成qos预期是困难的，尤其在qos预期本身逐个功能变化的情况下。

使用其他技术(例如，rdt技术)来预留容器的所需资源并接着将该容器指派给未提前知晓其需要的某一功能可能是困难的。因此，如图4中所示的增强的faas系统的各实施例被提供以标识应当为功能被指派到的容器预留的功能的资源需要(例如，多少高速缓存容量、多少存储器带宽等)。为了捕捉这一信息，按时间排序和云范围的历史机制两者被使用，藉此学习在之前运行过的功能需要什么；并且接着该信息可以被增强的faas系统用于设置rdt参数。

根据示例性实施例，如图39a中所例示的，faas框架3910促成从功能的历史3920中开发的按时间排序的反馈3912以及从并发且独立发生的功能的大量激活3930中开发的云规模(水平)反馈3914两者的持续应用。以此方式，它是可以在功能的运行时实现的某种形式的持续学习与群体学习的组合。

现在转向图39b，根据示例性实施例，可以为每一功能类型3950提供以下分量/方面：

1.1.qos清单向量3940，其将所期望的特定qos混合描述为{等待时间，吞吐量，可变性，利用，成本等}多维空间中被标准化到共用基准的向量，以使得每一qos向量在单位球体q内取值，其中数据被表示为使得数据之间的关系可以是幅值或尺度不变的。

2.资源成本函数的对应资源成本向量{cpu周期，存储器带宽，io带宽……等}3990，其被类似地标准化到共用(机器神经)基准，以使得成本函数(例如，代码例程)在单位球体c内取值。图38a的定制托管运行时系统类加载器3850可以生成资源成本向量的至少一个分量。例如，元数据文件加载器3856可以基于faas功能来标识该向量。

3.多值满足函数向量g＝{g1,g2,…gn}3960，其将向量q映射到c中的一组向量，例如，在来自q的多个不同的向量1(q),g2(q),...gn(q)满足给定向量q的情况下。

4.c和q两者都可以是底层连续域的离散化版本。同样，每一g可以被限于上限n，以使得存在要在其上进行搜索的满足资源指派的有限数目的变体。

5.可用性向量3970，其描述在给定时期的可用资源子集、或等效地c中的可用向量子集。

6.与qos有关的安全向量3980。

满足函数向量g3960可以通过应用本地历史(其中期望或指定的qos可以被经评估的资源开支来满足)来被迭代地训练(或学习)。资源开支可以通过遥测在每一主机或给定功能的容器内在运行时可用。另外，它们还可以通过混合从云中的其他主机或容器被训练的满足函数来更新。这种混合可以被加权，以使得本地历史相对于来自其他主机的时间输入被赋予更高权重；但是这些权重可以被有意地变异以达成进化学习。随着时间推移，这一解决方案可以允许对由例如机器或软件行为中的瞬态异常以及需求的内在变化而引起的瞬态波动有弹性的资源指派的持续进化。具体地，混合满足函数可能导致在将它们推广到云规模学习的同时应用箱式打包试探法(以选择最佳拟合满足向量)。

另外，根据示例性实施例，元语言加速器可以被实现以聚合与上述向量有关的遥测以评估用于特定工作负载的主机功能。可能存在用于所期望的qos的qos规范(例如清单)，并且该规范可包括关于租户的数据(例如，功能通过其获得服务的软件实现，诸如数据库系统、图像处理服务等)。可能存在累积和处理此类关于租户的数据的自动化方式。在一些情形中，服务(例如数据库)可指示其度量应当被忽略，例如，在它并未按标准方式操作的情况下。

根据示例性实施例，可以跨一些功能请求来跟踪端到端等待时间，这些功能请求在相同的功能请求经历多个服务阶段时累积时间。如果等待时间sla要求毫秒(ms)等待时间，则各个功能可以在本地被保持。示例性实施例可以保证停留在某一阈值等待时间之下，并且可以提供能够确保此类阈值等待时间的链路构造。

现在转向图39c，例示了根据实施例的用于预留恰适资源的方法。在方法3900的框3910中，可以标识功能的资源需要。在框3920中，可以基于所标识的资源需要在该功能被指派到的容器中预留资源。在框3930中，可以基于所标识的资源需要来设置rdt参数。

方法3900的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法3600的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法3900可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法3900的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例3901包括一种方法，其包括：标识功能的资源需要，基于所标识的资源需要在该功能被指派到的容器中预留资源，以及基于所标识的资源需要来设置rdt参数。

示例3902包括根据示例3901的方法，进一步包括调用加速器来评估用于该功能的工作负载的成本函数。

示例3903包括根据示例3901的方法，进一步包括构造链路以确保最小等待时间。

示例3904包括根据示例3901的方法，进一步包括使用至少一个向量来确保qos。

示例3905包括一种方法，其包括：标识功能的资源需要，基于所标识的资源需要在该功能被指派到的容器中预留资源，基于所标识的资源需要来设置rdt参数，调用加速器以评估用于特定工作负载的成本函数，构造链路以确保最小等待时间，以及使用至少一个向量来确保qos。

增强的轻量简档引导的优化(pgo)示例

代码优化对于无服务器执行可能是关键的，尤其因为未经优化的代码会引发膨胀的等待时间和印记，这会直接转换成faas范式中的成本。无服务器架构中的大部分代码可能是采用动态语言的，如node.js、python等。虽然pgo可以提供重要的线索来创建较大的类型专用的编译器区域且因而使类型校验以及从栈寄存器到存储器的值溢出最小化，但其在无服务器计算中的使用可能受到收集、分析和应用这些线索的cpu开销以及所导致的等待时间负担(tax)的约束。

由于执行功能的成本取决于以毫秒为单位测得的执行时间和所使用的存储器，因此减少等待时间和代码印记在faas环境中变得非常重要。通过增强的gpo方法，功能源代码可以首先被编译并且在执行期间可以创建动态简档。该简档可以被用于作出各种优化并改进用于将来功能执行的代码性能。简档对于功能的将来执行可以是有用的，因为不知道功能的将来执行将会被执行得多好或者特定功能的将来执行实际上是否会被执行。该过程可能是耗时的，该示例性实施例可以使用用于faas功能的硬件辅助来加速上述简档生成。例如，最后一个分支记录或其他硬件可以被实现以创建上述动态简档。动态简档的创建还可以部分地使用软件或软件-硬件组合来创建。

根据增强的pgo方法的又实施例，可以标识使功能性能降级的低级的与机器有关的瓶颈。在faas执行环境中，由于功能的后续执行可能在不同的机器上，因此理解低级机器依赖性可能是非常有用的。

最后，根据增强的pgo方法的又示例性实施例，使用增强的pgo方法的新优化可以被添加以减少功能等待时间，这些新优化诸如向量化数组操作(例如，在图像处理功能中)，使分支重定向最小化，以及使代码紧凑容适在更快速的高速缓存中。

增强的pgo方法的各实施例还能够实现在faas运行时中使用动态概况分析能力对异常的检测。一般来说，异常检测是标识异常事件的过程。在faas执行环境的上下文中，示例异常事件包括非法指令错误、对存储器区域的被禁止的访问、不成熟或非预期的功能退出。在检测到异常事件之际，增强的pgo方法将该检测报告给增强的faas系统的性能分析工具以供将来分析。异常事件可以是例如功能预期某些文件可用但它们实际上不可用。

现在转向图40a，根据示例性实施例，可能存在诸如图4中所示的增强的faas系统之类的增强的faas系统的若干增强，这些增强包括用于解决与代码优化4050有关的上述挑战的三个宽泛的类别：

1.第一类别涉及硬件辅助代码以及自动暴露于jit的代码两者的收集(4060)。

2.第二类别可以使标识影响代码执行的主要问题变得更容易，例如，抽象出机器性能数据之间的低级差别，这些差别逐机器地变化(4070)。即，在某一功能正在特定机器上执行且其运行缓慢时，与机器性能数据有关的此类信息可以指示该运行缓慢是由于机器没有以期望的频率运行而导致的而非由于功能中需要被优化的某些弱点而导致的。

3.第三类别包括对现有faas解决方案的多种优化或增强：

-将代码紧缩到最小的动态高速缓存和tlb印记中(4080)

-最小化分支重定向(4090)

-向量化数组操作(4095)

tlb是用于高速缓存用于计算机系统的存储器的地址转换信息的性能关键的结构。高的tlb未命中率对于系统和功能执行来说是成本高昂的。增强的faas系统的各实施例可以按照这样的方式来编译代码，以使得tlb未命中能够被降低或者tlb未命中损失能够被减少，例如通过在各个cpu核之间传达关于跨步式访问模式的信息并使用预取器来预测将来引用(以使得tlb未命中仅减缓数据被预取但是不影响实际执行的速度)。

类似地，增强的faas系统的各实施例优化代码编译，以使得已编译代码能够被容适在更小的动态页印记中(且因而减小了它在处理器高速缓存中消耗的空间)。类似地，代码所触碰的任何静态数据同样被紧缩，以使得被频繁访问的静态数据共处一处。例如，增强的faas系统的各实施例分析在不同编译器选项下的功能的执行历史和所收集的高速缓存统计数据，以选择代码中具有低时间局部性的那些已编译部分(例如，那些代码模块)并将它们放置在功能的地址空间中与代码的剩余部分不同的部分中，以提高l1指令高速缓存命中；且类似地将被更频繁地访问或在同时被访问的各个数据对象集中在一起，以使得l1数据高速缓存命中能够被提高。此类紧缩还降低了被同时访问的虚拟地址(用于指令和数据页)的平均数，以使得增强的faas系统中的tlb命中率被提高。

分支重定向指的是在指令取出器在先前前往错误的分支目的地的情况下将指令取出器重定向到正确的目的地的过程。例如，分支目标缓冲器(btb)是类似高速缓存的结构，其可以被增强的faas系统用来查找先前查看过的分支。btb提供的当前程序计数器的某些位包含关于潜在分支的信息。当关于潜在分支的猜测错误时，指令取出器将前往错误分支目的地；一旦发现此类错误分支目的地，则指令取出器需要被重定向到正确目的地。使用增强的faas系统，此类分支重定向能够被最小化。编译器能够使用许多不同的技术来减少分支重定向：在一个示例中，编译器可以改变分支的方向，以使得频繁被取的分支更容易被btb预测为被采用(通常向后分支比向前分支更容易被预测为被采用)；在另一示例中，编译器能够基于所估算的简档信息将预测提示用作分支指令中的前缀。

增强的faas系统的各实施例可以通过数组操作的向量化来进一步优化功能执行。例如，增强的faas系统的各实施例可以采用向量化编译器来将循环操作转变成一系列向量操作。此类向量化/转变允许增强的faas系统一次处理多对操作数上的一个操作，以使得功能执行的性能被提升。

由第一类别提取且由第二类别的增强转换的执行特性还可被用于驱动正交值，诸如实现即时qos、安全性和持久性以及信息架构(ia)唯一性，诸如rdt、sgx和3dxp。

现在转向图40b，根据示例性实施例，在方法4000的框4010中，可以编译功能源代码。在框4020中，在已编译源代码的执行期间，可以创建与该功能有关的动态简档。在框4040中，可以基于所创建的动态简档来创建新优化以降低功能等待时间。

方法4000的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法4000的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法4000可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法4000的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例4001包括一种方法，其包括：编译功能的源代码，在已编译源代码的执行期间创建与该功能有关的动态简档，以及基于所创建的动态简档来创建新优化以降低功能等待时间。

示例4002包括根据示例4001的方法，进一步包括在faas运行时中使用动态概况分析能力来检测异常。

示例4003包括根据示例4002的方法，进一步包括将检测结果报告给性能分析工具。

示例4004包括根据示例4001的方法，进一步包括经由编排器来维持简档映射。

示例4005包括一种方法，其包括：标识功能的资源需要，基于所标识的资源需要在该功能被指派到的容器中预留资源，基于所标识的资源需要来设置rdt参数，调用加速器以评估用于特定工作负载的成本函数，构造链路以确保最小等待时间，使用至少一个向量来确保qos，在faas运行时中使用动态概况分析能力来检测异常，将检测结果报告给性能分析工具，经由编排器来维持简档映射。

以时间顺序记录的指纹示例

各个功能在它们的执行期间可能展现出不同的特性，并且以不同的速率来使用各种资源，如cpu、存储器、网络等。理解这些特性并将它们与各个功能进行关联(作为它们的需求指纹)对于高效的资源分配和调度是重要的。在图41d中示出了示例性需求指纹。然而，需求指纹在没有大量在先实验的情况下可能无法容易地获得——许多功能可在几天、几个星期、几个月的过程中被执行多次。

根据诸如图4中所示的增强的faas系统之类的增强的faas系统的示例性实施例，提供了用于自动生成关于不同资源在功能执行的各个阶段的使用的详细报告以及在多次执行的基础上生成需求指纹的过程。一些资源(例如cpu)可能在功能启动时被繁重使用，而一些其他资源(例如，存储器、高速缓存)可能在之后的部分期间被繁重使用。一个功能还可以以调用其他功能来结束。此类详细报告可以被称为功能纪事(functionchronicle)。因而，随着时间推移，如图41a中所示，每一次执行功能时，可以获得功能的各种性能、功率和缩放特性或敏感度并且丰富的历史构建成为一个成熟的需求指纹(demandfingerprint)。如图41b中所例示的，需求指纹信息可以被用于调度功能并经由资源管理器4110来将资源分配给功能以实现高效的资源管理，资源管理器4110可以被实现在编排器或csp的服务器中。需求指纹可以与功能调用链相关联，该功能调用链具有源调用方(特定客户端)且具有功能调用的特定参数值。

根据图41b中所示的示例性实施例，需求指纹可以在功能创建时被创建，且可仅包含关于功能参数的细节，如存储器要求和超时。在功能执行期间，可以记录各种资源消耗(例如，cpu、存储器)。在功能执行结束时，可以推断不同的资源使用模式，诸如该功能是cpu/存储器/网络密集的，或者功能被执行时cpu/存储器密集的特定阶段。通过多次功能执行，需求指纹增长并且可以获得关于该功能的资源使用模式的更多(准确)信息。该需求指纹可以被用于用于功能的进一步执行的资源调度。在功能链接的情形中，资源管理器4110可以基于被链接的功能的需求指纹通过分配资源(cpu、存储器)来提前准备用于执行被链接的功能的资源。

现在转向图41c，根据示例性实施例，在方法4100的框4120中，资源特性可以与被执行的功能相关联以生成被执行的功能在每一执行阶段的需求指纹。在框4130中，例如编排器(未示出)可以生成关于不同资源在功能的多个执行阶段的使用的详细报告。在框4140中，可以基于所生成的报告来调度功能的执行，并且可以向功能分配资源。

方法4100的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法4100的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法4100可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法4100的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例4101包括一种方法，其包括：将资源特性与被执行的功能进行关联以生成被执行的功能在每一执行阶段的需求指纹，经由编排器来生成关于不同资源在功能的多个执行阶段的使用的详细报告，基于所生成的报告来调度功能的执行并且向功能分配资源。

示例4102可包括根据示例4101的方法，进一步包括与功能的参数以及调用功能的租户相关联地生成需求指纹。

示例4103可包括根据示例4101的方法，进一步包括实现序列分析机器学习模型以生成该需求指纹。

示例4104包括一种方法，其包括：将资源特性与被执行的功能进行关联以生成被执行的功能在每一执行阶段的需求指纹，经由编排器来生成关于不同资源在功能的多个执行阶段的使用的详细报告，基于所生成的报告来调度功能的执行并且向功能分配资源，与功能的参数以及调用功能的租户相关联地生成该需求指纹，以及实现序列分析机器学习模型来生成该需求指纹。

用于自动化深度概况分析的框架方法和装置

功能以及它们在其中被执行的其相关联的执行引擎(诸如容器和/或主存装置)的相互不透明性在对它们的执行进行概况分析、调试、审计和优化方面引入了严峻挑战。诸如图4中所示的增强的faas系统之类的增强的faas系统的示例性实施例提供了用于简化功能的性能追踪以及集成从执行引擎获得的信息的方法，这些方法中的一些可以是硬件辅助的。在此类集成中，主存引擎/容器或平台的细节可以被适当地保护以免于被揭露，以达成期望水平的执行引擎透明性，并且功能的架构神经行为可以被概况分析、追踪、按时间线排序以供调试、微调和审计目标。

现在转向图42a，增强的faas框架包括虚拟概况分析api4250，功能客户端4260可以经由该api获得经时间或事件穿孔的踪迹以及不透明的标记4270(例如，索引或数据句柄)。经时间或事件穿孔的踪迹可以用在踪迹收集期间发生的事件(例如，中断或其他信号、超时、页错误等)、从功能执行开始以精细粒度的时间为单位的它们发生的时间来注释。不透明的标记4270可以根据在功能客户端4260与执行服务提供商之间协商的透明性程度被呈现给执行引擎4280以获得来自执行环境4280的各种经标准化聚合测量4290。不透明的标记4270可以启用对信息对象的引用而无需对所引用的对象的内容或结构具有访问权的引用器。

不透明的标记4270可以提供向获得合适特权的工具提供接收基础设施级别且因此可能不对正在执行的功能(其在低级特权级别运行)可用的各种统计数据的方式。以此方式，平台级事件或统计数据可以被适当地过滤或映射到一些引用单元并接着被混合到踪迹中。例如，不透明的标记4270可以在稍后被转换成“cpu在时间0x12345进入睿频频率g”或者“在时间0x56789由于热断路引起的存储器错误被检测到并被纠正”等。

聚合测量可以被获得以一起分析和表征系统和功能的行为，因为一般来说可能不必要以最细微的细节水平来知晓系统中的每一件事。知晓例如在功能正在执行的时间跨度期间以平均频率x发生页错误或者系统经历了热事件或未经历任何热事件可能是足够的。根据示例性实施例，可以执行获得完整测量系列，虽然在一些实例中，这样做可能过于显露且过于昂贵以致于在稍后无法存储和分析。从功能执行引擎4280获得的聚合测量可以被进一步标准化以获得对所获得的聚合测量的分析的改进的性能。经标准化的聚合测量4920可包括诸如交换使用之类的软件度量和诸如l1高速缓存未命中之类的硬件度量。

虚拟概况分析可以在运行时发生并且可以由执行功能的容器来执行。所生成的踪迹包括在功能执行的过程中的硬件和软件度量的集合，并且还可基于在功能执行或功能链接期间发生的不同事件来分类。不透明的标记4270可以由容器层、虚拟机层、或硬件层生成。可任选的硬件延伸提供对虚拟功率管理单元(pmu)能力的直接访问以获得从功能内抽象的但灵活的自表征。

现在转向图42b，根据示例性实施例，在方法420的框4210中，功能可以获得经时间或事件穿孔的踪迹以及不透明的标记。在框4220中，不透明的标记可以被呈现给功能的执行引擎，诸如执行功能的容器，以获得来自执行环境的聚合测量。在框4240中，可以向该功能提供对虚拟pmu的直接访问。

方法4200的实施例可在系统、装置、计算机、设备等(例如诸如，本文所描述的那些)中被实现。更具体地，方法4200的硬件实现可包括可配置逻辑(诸如例如pla、fpga、cpld)、或者使用电路技术(诸如例如，asic、cmos或ttl技术)的固定功能逻辑硬件，或其任何组合。替代地或附加地，方法4200可在一个或多个模块中被实现为存储在机器或计算机可读存储介质(诸如，ram、rom、prom、固件、闪存等)中以由处理器或计算设备执行的逻辑指令集。例如，用于实现组件的操作的计算机程序代码能以一种或多种os适用/适当的编程语言的任何组合来进行编写，包括诸如python、perl、java、smalltalk、c++、c#之类的面向对象编程语言，以及诸如“c”编程语言或类似编程语言之类的常规过程式编程语言。

方法4200的实施例或部分可以在固件、应用(例如，通过应用编程接口(api))或在操作系统(os)上运行的驱动程序软件中实现。另外，逻辑指令可包括汇编程序指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、状态设置数据、用于集成电路的配置数据、使对于硬件(例如，主机处理器、中央处理单元/cpu、微控制器等)而言是原生的电子电路和/或其他结构组件个性化的状态信息。

附加注解与示例

示例4201包括一种方法，其包括：经由功能获得该功能的经时间或事件穿孔的踪迹和不透明的标记，将该不透明的标记呈现给与该功能相关联的执行引擎以从执行引擎获得关于该功能的信息，以及向该功能提供对一个或多个硬件组件的直接访问，其中该不透明的标记用于引用数据对象而无需对该数据对象的内容或结构具有任何访问权。

示例4202包括示例4201的方法，进一步包括将有符号数据存储到要被供应给受信实体的飞地中。

示例4203包括示例4201的方法，进一步包括对关于不透明的标记所捕捉的系统遥测进行加密，其中该加密用于使用应用特定的设置来执行。

示例4204包括示例4201的方法，进一步包括生成用于应用的api以确定独立于执行环境的概况分析点。

示例4205包括示例4201的方法，进一步包括将特权与该功能和概况分析数据解耦。

示例4206包括示例4201的方法，进一步包括管理安全点以插入签条/令牌。

示例4207包括一种方法，其包括：经由功能获得经时间或事件穿孔的踪迹和不透明的标记，将该不透明的标记呈现给执行引擎以从该执行引擎获得信息，向该功能提供对虚拟功率管理单元的直接访问，将有符号数据存储到要被供应给受信实体的飞地中，使用应用特定的设置来加密所捕捉的页，生成用于应用的api以确定独立于执行环境的概况分析点，将特权与该功能和概况分析数据解耦，以及管理安全点以插入签条/令牌。

用于功能执行的服务器选择

现在转向图43a，示出了一个示例，其中增强的faas系统的用户接口处置器4300(例如，api代理，诸如举例来说api网关)处置会话状态管理。在所例示的示例中，用户接口处置器4300生成包括功能上下文标识符(id)4304的令牌4302(例如，数据“名称”)。功能上下文id4304唯一地标识与用于执行该功能的传入请求4306相关联的功能的上下文4316。更具体地，该功能可通过可任选的字段来定属性，该可任选的字段将上下文4316描述为数据集构造的身份的近似表示。在一个示例中，令牌4302由用户接口处置器4300的名称构造api使用例如在各种全局唯一id(uuid)、请求4306的源(例如，在应用定义的功能映射解决方案中功能的调用方)、功能的特定参数、文件系统路径名、弹性分布式数据集(rdd)谱系(例如，在apachespark中)、关系数据库中的表空间范围等上应用的设置函数(例如，bloom滤波器)来构造。

在所例示的示例中，编排器4308基于令牌4302(以及潜在地要更详细地讨论的其他因素)来选择服务器位置，并且将令牌4302连同功能调用4310一起传递到所选的服务器位置。在所例示的示例中，功能调用4310和令牌4302被传递到包括包含上下文4316的本地高速缓存4314的第一服务器4312，其中上下文4316促成功能对状态数据(例如，许可、认证状态、与事务有关的数据等)的检取。所例示的解决方案因此实现在功能执行期间计算被推送到所使用的数据。在这一方面，达成对状态数据的更高效的检取，因为上下文4316在本地被高速缓存(例如，在实施功能特定的关联性时按需创建具有相同状态的功能处理请求的情形)。

服务器位置可以基于附加因素来选择。例如，第一服务器4312、第二服务器4318、第三服务器4320等的相对位置成本(例如，到该位置的数据传递/带宽、将数据存储在该位置处和/或在该位置处处理数据的成本)可以在别处指定功能调用4310和令牌4302的传递。在又一示例中，编排器4308基于服务质量(qos)要求(例如，可靠性、处理速度等)来选择服务器位置。在此类情形中，如果第二服务器4318能够满足qos要求而第一服务器4312无法满足qos要求，则功能调用4310和令牌4302可以被传递到第二服务器4318。

在另一示例中，编排器4308基于功能的先前执行的散列结果来选择服务器位置。更具体地，如果

dataid2＝hash(fn(dataid1)

当fx(dataid2)被调用时，编排器4308可以决定是要移动dataid2还是功能fx()。

服务器位置还可以是数据被流传输(例如，经由第二或第三阶处理消耗)的节点。在其他示例中，服务器位置基于与功能相关联的历史(例如，时间/时间性历史)、请求源和/或功能调用树(即，包括正被调度的功能的一系列调用)来选择。

所例示的解决方案通过事件定向、在响应于请求4306按需生成功能调用4310的程度上增强faas系统。另外，所例示的解决方案通过最少管理来增强faas系统，因为服务器位置的选择被抽象远离用户。此外，faas系统以高可缩放性被增强，因为功能调用4310随着请求4306的数目自动缩放。另外，所例示的解决方案通过原子规模单元、在功能是计算规模单元的程度上增强faas系统。所例示的解决方案还使得消费者能够仅在功能调用4310运行时进行支付并因此向faas系统提供粒度计费。另外，所例示的解决方案减少了在数据库中维持上下文4316的任何需要，这原本会使得对上下文4316的检取不那么高效。

现在转向图43b，示出了管理功能调用的方法4322。方法4322可以被普遍地实现在增强的faas系统中，诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、和/或系统400(图4)。更具体地，方法4322可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框4324提供了生成令牌，该令牌唯一地标识与用于执行功能相关联的传入请求相关联的功能的上下文。该传入请求可以是触发事件，诸如举例来说iot事件和/或faas事件，诸如对执行由用户开发的功能的用户请求。在一个示例中，框4324由用户接口处置器来进行，诸如举例来说已经讨论过的用户接口处置器4300(图43a)。在框4326基于该令牌来选择服务器位置，其中所例示的框4328在所选服务器位置处调用功能。在所例示的示例中，上下文促成功能对状态数据的检取(例如，功能从上下文检取状态数据)。框4326和4328可以由编排器进行，诸如举例来说已经讨论过的编排器4308(图43a)。所例示的方法4322因此在事件取向、最少管理、高可缩放性、原子规模单元和粒度计费方面增强了faas系统。另外，所例示的方法4322减少了在单独的数据库中维持上下文并且每次都要访问该上下文的任何需要，这原本由于远程访问的附加等待时间会低效得多。

图43c示出了管理功能调用的更详细的方法4330。方法4330可以被普遍地实现在增强的faas系统中，诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、和/或系统400(图4)。更具体地，方法4330可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框4332提供了生成令牌，该令牌唯一地标识与用于执行功能相关联的传入请求相关联的功能的上下文。该传入请求可以是触发事件，诸如举例来说iot事件和/或faas事件。在一个示例中，框4332由用户接口处置器来进行，诸如举例来说已经讨论过的用户接口处置器4300(图43a)。在框4334基于该令牌以及以下一者或多者来选择服务器位置：与功能相关联的时间历史、请求源、功能调用树、位置成本、qos要求、或功能的先前执行的散列结果。在所例示的示例中，服务器位置被选择为包括包含该上下文的本地高速缓存或者使用于执行功能的性能、qos要求或数据关联性最大化的位置。服务器位置还可以是数据被流传输(例如，经由第二或第三阶处理消耗)的节点。

框4336在所选择的服务器位置处调用功能，其中该上下文促成该功能对状态数据的检取。在框4338，所选择的服务器位置被存储到与该功能相关联的时间历史。因而，时间历史可以被用于作出用于该功能的将来服务位置决策。在一个示例中，框4334、4336和4338由编排器进行，诸如举例来说已经讨论过的编排器4308(图43a)。所例示的方法4330因此在事件取向、最少管理、高可缩放性、原子规模单元和粒度计费方面增强了faas系统。

图43d示出了faas系统4340，其中功能调用的位置基于请求源来选择。更具体地，第一客户端4342(“客户端1”)向faas系统4340发出用于执行特定功能的第一请求4344(“请求a”)。第一客户端4342还可以向faas系统4340发出用于执行同一功能的第二请求4346(“请求b”)。另外，在所例示的示例中，第二客户端4348(“客户端2”)向faas系统4340发出用于执行该功能的第三请求4350(“请求c”)。在此类情形中，faas系统4340可以将请求a调用4352和请求b调用4354发送到共用服务器，诸如举例来说第i服务器4354(“服务器i”)以降低移动上下文和/或状态数据的可能性。作为对比，所例示的faas系统4340将请求c调用4356发送到第j服务器4358(“服务器j”)，因为第三请求4350来自第二客户端4348(例如，不同的请求源)。

图43e示出了faas系统4360，其中功能调用的位置基于功能调用树来选择。更具体地，向faas系统4360发出第一功能调用树4362(“功能调用树1”)和第二功能调用树4364(“功能调用树2”)。在此类情形中，faas系统4360可以将对应于第一功能调用树4362的第一调用集4366发送到第i服务器4354以降低移动与第一功能调用树4362相关联的上下文和/或状态数据的可能性。类似地，所例示的faas系统4360将第二调用集4368发送到第j服务器4358以降低移动与第二功能调用树4364相关联的上下文和/或状态数据的可能性。

附加注解与示例

示例4301包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算设备执行时致使该计算设备：生成唯一地标识与用于执行功能的传入请求相关联的功能的上下文的令牌；基于该令牌以及以下一者或多者来选择服务器位置：与该功能相关联的时间历史、请求源、功能调用树、位置成本、服务质量(qos)要求、或该功能的先前执行的散列结果，其中服务器位置被选择为包括包含该上下文的本地高速缓存；在所选择的服务器位置处调用该功能，其中该上下文促成该功能对状态数据的检取；以及将所选择的服务器位置存储到时间历史。

示例4302包括示例4301的至少一种计算机可读存储介质，其中服务器位置被选择为数据被流传输的节点。

跨域调用传递示例

最常在远程过程调用(rpc)中发生的跨域控制传递在分布式应用和服务中是频繁的，并且其高成本可以归因于相关联的上下文切换、跨栈复制(例如，在管理程序/监管程序的控制之下)和安全控制传递。rpc已经成为用于构建客户端-服务器或对等交互的关键机制。然而，faas环境中的高效rpc实现可能是具有挑战性的。实际上，在其他问题(例如，通过较轻量的容纳装置的高效的隔离、服务水平协议/sla支持等)得到解决时，高效的跨域控制传递的重要性可能增长。

在rpc交互期间，调用方可以(a)从其用户空间移动到内核空间，在内核空间中(b)在验证各种能力之后(c)调用参数/数据被编组并且(d)通过恰适的传输机制被用消息传递至被调用方。测量示出在经优化的gprc(谷歌rpc)实现中控制面开销占据超过90％的周期。在一个示例中，诸如举例来说nff-go项目(例如，github.com/intel-go/nff-go)之类的云-原生数据面(例如，网络中携带用户话务的那部分)工作已经确立高效的rpc对于网络功能虚拟化可能是关键的(例如，具备每秒数亿请求的能力，每个分组一个请求)。同时，将faas范式应用于数据面处理的尝试可能暴露对用于访问os、平台和硬件加速以及功能到功能链接的统一机制的需要以避免对特定框架的依赖性(例如，在不同的云环境中以相同的方式作出功能调用，如在亚马逊lambda^tm、openwhisk^tm、gcp/谷歌云平台^tm和nff-go^tm中)。

以上过程(a)-(d)中所涉及的操作可包括跨不同域执行的样板代码序列，这涉及使它们在计算上变得昂贵的监管干预。实际上，类似的开销还适用于被调用方侧和结果返回路径。当其他硬件特征变得更快(例如，在连续硬件技术代际中)时，这些开销成比例地称为“饼”的较大部分。

尽管最近开发的指令可促成对以上“宏”或切饼器操作的硬件实现，但是仍然存在改进空间。例如，缺少聚焦于使控制传递高效的底层机制可能导致与较频繁的上下文切换、跨栈复制、传递安全和/或监管干预相关联的较高成本。如将更详细地讨论的，虚拟硬件线程和统一资源标识符(uri)调用指令可以被用于提高跨域控制传递的效率。

现在转向图44a，示出了跨域环境4400，其中第一域4402中的调用器4404(例如调用方)调用正在第二域4406中“虚拟地等待”调用的功能。一般来说，第二域4406中的核可包括监视逻辑4408(例如，逻辑指令、可配置逻辑、固定功能硬件逻辑等、或其组合)和多个虚拟硬件线程(vhtr)，诸如举例来说虚拟硬件线程4410。虚拟硬件线程4410可以一般地是被调度硬件用来在多个线程或虚拟网络功能(vnf)之间细分核资源和循环的线程调度结构。从软件和操作系统观点来看，vhtr类似于常规的cpu核。在一些实施例中，vhtr被固定到线程且与多个功能相关联以辅助调度和执行。在一些实施例中，硬件调度器在各vhtr之间适配cpu切片。例如，一百个或更多个vhtr可以被调度以共享两个处理核的cpu循环。相应地，数千个vhtr可以被分配并锁定到各线程，只要存在足够的存储。

在所例示的示例中，虚拟硬件线程4410被置于暂停状态(“p”状态)，其中执行和轮询被挂起。在虚拟硬件线程4410在p状态中等待的同时，它既不接收处理器循环也不进行轮询。当调用器4404(例如，经由calluri2指令)使被调用功能的一个或多个调用参数入列到被监视位置(诸如举例来说队列4412或由被调用方监视的其他位置)中时，所例示的调用器4404(例如经由等待命令)使本地虚拟硬件线程4418进入p状态。另外，监视逻辑4408可以检测调用参数在队列4412中的存在。调用参数在队列4412中的存在可以经由预先存在的微架构能力来检测，微架构能力诸如举例来说用户级中断(例如，umonitor/umwait)、存储器触发(例如，monitor/mwait)、事务同步扩展(tsx)机制生成的对到被标记的高速缓存行的加载或存储的指示、处理器间中断(ipi)与暂停(hlt)指令和轻量中断服务例程(isr)的组合、向下兼容的轮询循环等。

在一个示例中，监视逻辑4408是硬件调度器的一部分，其选择处于等待状态中的核并通过传递功能地址、指向调用参数的指针、以及标识可以被用于结果的将来返回的请求的令牌来触发所选核的执行。如果不存在正在等待的核，则硬件调度器可以支持用于每一核的任务的队列(例如，硬件队列管理器/hqm)，也可以使用支持参数传递和队列的umonitor/umwait的扩展语义(例如，报告是否有核正在p状态中等待)。因而，响应于调用参数正在队列4412中，监视逻辑4408将虚拟硬件线程4410置于执行状态(“e”状态)中。在所例示的示例中，虚拟硬件线程4410使被调用功能的一个或多个结果入列到被监视位置(诸如举例来说队列4414或由调用方监视的其他位置)中。监视逻辑4416(例如，逻辑指令、可配置逻辑、固定功能硬件逻辑等、或其任何组合)可以检测结果在队列4414中的存在。结果在队列4414中的存在可以经由预先存在的微架构能力来检测，微架构能力诸如举例来说用户级中断、存储器触发、tsx机制生成的对到被标记的高速缓存行的加载或存储的指示、ipi与hlt指令和轻量isr的组合、向下兼容的轮询循环等。响应于结果在队列4414中，所例示的监视逻辑4416将虚拟硬件线程4418置于执行状态中，以使得它可以消耗这些结果并执行进一步的操作。

现在转向图44b，示出了操作远程过程被调用方的方法4420。方法4420可以被普遍地实现在增强的faas系统中，诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、和/或系统400(图4)。在实施例中，方法4420被实现在被调用方域中，诸如举例来说已经讨论过的第二域4406(图44a)。更具体地，方法4420可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框4422提供了将虚拟硬件线程置于暂停状态中，其中执行和轮询被挂起。在所例示的示例中，虚拟硬件线程与被调用功能相关联，且被调用功能是远程过程。可以在框4424作出关于被调用功能的一个或多个调用参数是否在被监视位置中的确定。如果否，则所例示的方法4420重复框4424。一旦确定调用参数已经被检测到，框4426提供了响应于调用参数在被监视位置中而将虚拟硬件线程置于执行状态中。

图44c示出了一种操作远程过程调用方的方法4430。方法4430可以被普遍地实现在增强的faas系统中，诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、和/或系统400(图4)。在实施例中，方法4430被实现在调用方域中，诸如举例来说已经讨论过的第一域4402(图44a)。更具体地，方法4430可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框4432提供了将虚拟硬件线程置于暂停状态中，其中执行和轮询被挂起。在所例示的示例中，虚拟硬件线程与被调用功能的调用器相关联，且被调用功能是远程过程。可以在框4434作出关于被调用功能的一个或多个结果是否在被监视位置中的确定。如果否，则所例示的方法4430重复框4434。一旦确定结果已经被检测到，框4436提供了响应于结果在被监视位置中而将虚拟硬件线程置于执行状态中。

附加注解与示例

示例4401包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算设备执行时致使该计算设备：将虚拟硬件线程置于其中执行和轮询被挂起的暂停状态中，其中该虚拟硬件线程与被调用功能相关联且被调用功能是远程过程，检测被监视位置中的被调用功能的一个或多个调用参数，以及响应于一个或多个调用参数在被监视位置中而将该虚拟硬件线程置于执行状态中。

示例4402包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算设备执行时致使该计算设备：将虚拟硬件线程置于其中执行和轮询被挂起的暂停状态中，其中该虚拟硬件线程与被调用功能的调用器相关联且被调用功能是远程过程，检测被监视位置中的被调用功能的一个或多个结果，以及响应于一个或多个结果在第二位置中而将第二虚拟硬件线程置于执行状态中。

异构数据流的统一示例

图45a示出了faas架构4500，其中分组穿越网络边界4502，且网络栈一般地包括若干层(例如，l7-应用层，l4-传输层，l3-网络层，l2-数据链路层等)。例如，一个或多个数据链路(例如，开放系统互连/osi模型的层l2)功能4508促成广域网(wan)中的毗邻网络节点之间或同一局域网(lan)段上各节点之间的数据传递。另外，一个或多个网络(例如，osi模型的层l3)功能4512可以处置分组转发，并且一个或多个传输(例如，osi模型的层l4)功能4514为应用提供主机到主机的通信服务。

在一个示例中，api网关4506拦截来自各个功能4504(4504a-4504d)的远程过程调用(rpc)，各个功能4504诸如举例来说第一应用层(例如，osi模型的l7)功能4504a、第一数据面功能4504b(例如web功能)、第二数据面功能4504c(例如代理功能)、第二应用层功能4504d等。支持超文本传输协议(http)的所例示的api网关4506还拦截来自一个或多个基础设施功能4510的rpc。加速的rpc(a-rpc)调用器4520可以进行与被拦截rpc相关联的网络功能的实例化。例如，api网关4506可以拦截来自第一应用层功能4504a的rpc，其中如果被拦截rpc与第二应用层功能4504d相关联，则调用器实例化第二应用层功能4504d。

具体地，在prc的分组化之前rpc被拦截，并且实例化绕过网络栈的传输层和/或网络层。因而，所例示的解决方案提供了不需要穿过整个网络栈的新应用二进制接口(abi)。实例化还可以绕过一个或多个加密操作、一个或多个调用器-目标握手消息等。相应地，所例示的api网关4506、功能4504和调用器4520构成了启用更高效的实例化和路由的faas功能到功能加速逻辑4522。

所例示的功能4504和各种事件源4516(例如，状态和配置数据库)受到一个或多个控制面功能4518的支持。另外，事件源4516可以向网络边界4502、数据链路功能4508、网际协议(ip)逻辑4524(例如，ipv4、ipv6)、传输控制协议(tcp)逻辑4526、与api网关4506交换tcp消息的安全套接字层(ssl)逻辑4528、用户数据报协议(udp)逻辑4530、和域名服务器(dns)逻辑4532提供上下文数据，这些逻辑在所例示的示例中全部被加速。所例示的架构4500还包括地址解析协议(arp)逻辑4534。在一个示例中，网络边界4502、数据链路功能4508、ip逻辑4524、tcp逻辑4526、ssl逻辑4528以及api网关4506是faasapi-网关加速逻辑4536。

第一应用层功能4504a和第二应用层功能4504d能够经由代表性状态传递(rest)、grpc、a-rpc等来调用。附加路径4538可以被提供以用于包含旧式样式协议(诸如举例来说在抵达api网关4506之前要被处理的边界网关协议(bgp))的分组。旧式样式协议可能影响其他功能的一些配置。例如，bgp可以被用于更新进而由一些ip功能使用的路由表。相应地，所例示的附加路径4538使得api网关4506的功能性在恰适的时候被限于仅仅几个协议。实际上，附加路径4538可以处置rest和grpc调用，其中api网关4506仅负责a-rpc调用(包括它们的再循环，例如f1＝>f2＝>f3等，而无需低级的网络栈)。所例示的架构4500因此统一了完整的l2-l7网络栈和l7应用功能的实现，并且通过将api网关4506自身暴露为基础设施(或运行时)功能来实现各种快捷方式。所例示的架构4500还消除了与不同设计的应用(诸如nginx)相关联的性能问题，这些应用原本可能要求调用穿过内核网络栈。

图45b示出了一种用于操作用于faas服务的运行时框架的方法4540。方法4540可以被普遍地实现在增强的faas系统中，诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、和/或系统400(图4)。在实施例中，方法4540被实现在faas架构中，诸如举例来说已经讨论过的faas架构4500(图45a)。更具体地，方法4540可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框4542提供了在rpc的分组化之前拦截来自网络栈的应用层处的第一网络功能的rpc。框4544可以进行与(例如应用层处的)rpc相关联的第二网络功能的实例化，其中该实例化要绕过网络栈的传输层或网络栈的网络层中的一者或多者。在一个示例中，该实例化还绕过一个或多个加密操作和/或一个或多个调用器-目标握手消息。

附加注解与示例

示例4501包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算设备执行时致使该计算设备：在远程过程调用的分组化之前拦截来自网络栈的应用层处的第一网络功能的远程过程调用，以及进行与该远程过程调用相关联的第二网络功能的实例化，其中该实例化用于绕过网络栈的传输层或网络栈的网络层中的一者或多者。

示例4502包括示例4501的至少一种计算机可读存储介质，其中该实例化用于绕过一个或多个加密操作以及一个或多个调用器-目标握手消息。

响应对象定制示例

在一个示例中，faas架构使用标准数据互换格式来在各功能之间传递参数和自变量，接收被串行化为此类格式的调用请求响应，这些格式包括的一种常用格式是轻量且可以被容易地读/解析的json(javascript对象符号)。功能的不同调用实例可以使用响应对象的不同字段，其中响应对象可以以json对象的形式被串行化并返回。例如，功能“funcgetitems”可返回一个项列表，每一项包含一个详细的字段列表。

asamplejsonresponsereturnedbyfuncgetitems(funcgetitems所返回的样本json响应)：

可能遇到这样的一个场景，其中功能“funca”和“funcb”各自调用“funcgetitems”，但它们各自仅使用每一项的几个字段。

本文所描述的技术基于每一调用方的要求/签名来定制要被定制的串行化响应(或参数)对象。例如，对“funcb”返回的响应可以被压缩成以下json对象，其仅包含必要的/恰适的数据字段。

例如，图46a展示了功能4600可以返回一数据字段集4602(例如，“item_id”到“ready_by_time”)。如果第一调用实例4604(例如，“funca”的lambda/匿名调用器)对功能4600的第一调用被检测到，则字段集4602的第一子集4606(例如，仅“item_id”和“fee”)可以被标识，其中第一子集4606与第一调用实例4604相关。此外，对第一响应对象4612(例如，json对象)的第一重布局(例如，重配置、重排序)可以基于第一子集4606来进行。如将更详细地讨论的，第一重布局可以过滤第一响应对象4612以仅包括第一子集4606，对第一响应对象4612重排序以将第一子集4606列举在字段集4602中的其余字段之前等等。

类似地，如果第二调用实例4608(例如，“funcb”的lambda/匿名调用器)对功能4600的第二调用被检测到，则字段集4602的第二子集4610(例如，仅“item_id”和“start_time”)可以被标识，其中第二子集4610与第二调用实例4608相关。此外，对第二响应对象4614(例如，json对象)的第二重布局可以基于第二子集4610来进行。同样地，第二重布局可以过滤第二响应对象4612以仅包括第二子集4610，对第二响应对象4614进行重排序以将第二子集4606列举在字段集4602中的其余字段之前等。因此，由增强的faas系统提供的所例示的解决方案压缩了响应对象4612、4614，并且实现更高效的联网/带宽使用、更少的处理开销、增强的性能、最小化的管理和更大的可缩放性。

在一个实施例中，压缩机制可以被实现为在响应被发送回之前对每一调用方匿名的功能(例如，功能原义、lambda抽象、lambda表达)的相关字段的收集。在一个示例中，为每一调用方注册相关数据字段的标签/偏移，并且相关数据字段的标签/偏移可以被进一步高速缓存在被调用方lambda附近的软件/硬件结构中。例如，查找表可以通过调用方id/ip/地址来进行索引以检取将被应用于原始结果的过滤器。过滤器可以选择类似于以上示例的几个感兴趣的字段。另外，过滤器还可以对响应/json对象重格式化以首先列举/提出感兴趣的字段并将剩余的字段/数据放在后面。尽管json压缩在本文中被用于促成讨论，但是消息参数的其他编码(诸如举例来说grpc二进制编码)也可以被使用。

在一个示例中，提供过滤器代码(例如，方法存根、lambda)作为调用方实现(例如，签名、方法存根)的一部分。过滤器代码还可以由编译器/运行时工具导出。在实施例中，在执行返回指令之前，经由跳转表(例如，到执行为每一调用方定制的压缩/重布局的代码的间接跳转)来实现将原始结果发送回之前对原始结果进行过滤。可以开发其他指令集架构(isa)和硬件支持来高速缓存间接跳转的目标(例如，类似于转换后备缓冲器/tlb高速缓存)或预测间接跳转的目标(例如，类似于分支目标缓冲器/btb)。

现在转向图46b，示出了定制调用实例的响应对象的方法4620。方法4620可以被普遍地实现在增强的faas系统中，诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、和/或系统400(图4)。更具体地，方法4620可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框4622检测第一调用实例对返回字段集的功能的第一调用。在框4624可以标识该字段集的第一子集，其中第一子集要与第一调用实例相关。另外，框4626基于第一子集来进行第一响应对象的第一重布局。在一个示例中，框4626包括过滤第一响应对象以仅包括第一子集。框4626还可包括对第一响应对象重排序以将第一子集列举在该字段集中的其余字段之前。也可使用其他重布局技术。

在一个示例中，在框4628检测第二调用实例对该功能的第二调用。在框4630可以标识该字段集的第二子集，其中第二子集要与第二调用实例相关。所例示的框4632基于第二子集来进行第二响应对象的第二重布局，其中第二重布局与第一重布局不同。框4632可包括过滤第二响应对象以仅包括第二子集，对第二响应对象重排序以将第二子集列举在该字段集中的其余字段之前等。因此，所例示的方法4620压缩了响应对象，并且启用更高效的联网/带宽使用、更少的处理开销、增强的性能、最小化的管理和更大的可缩放性。

附加注解与示例

示例4601包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算设备执行时致使该计算设备：检测第一调用实例对返回字段集的功能的第一调用，标识该字段集的第一子集，其中第一子集要与第一调用实例相关，以及基于第一子集来进行第一响应对象的第一重布局。

示例4602包括示例4601的至少一种计算机可读存储介质，其中第一重布局用于过滤第一响应对象以仅包括第一子集。

示例4603包括示例4601的至少一种计算机可读存储介质，其中第一重布局用于对第一响应对象重排序以将第一子集列举在该字段集中的其余字段之前。

示例4604包括示例4601的至少一种计算机可读存储介质，其中该指令在被执行时致使该计算设备：检测第二调用实例对该功能的第二调用，标识该字段集的第二子集，其中第二子集要与第二调用实例相关，以及基于第二子集来进行第二响应对象的第二重布局，其中第二重布局与第一重布局不同。

参数编组示例

参数编组涉及将对象的存储器表示转变为适于存储或传输到其他软件应用的另一格式。因此，编组通过将对象转换成串行化形式促成了远程对象之间的通信。在faas框架中用于rpc的参数的编组可能面对由于正被传递的大量数据而引起的瓶颈挑战。无论是文本编码(例如，具有json的rest)还是二进制编码(例如，grps、flatbuffers、apachethrift)要被用于传递功能参数，该瓶颈挑战可能仍然长期存在，因为“线缆上的”数据与存储器中的数据以不同方式被格式化并且存在持久的串行化/解串行化。

图47a示出了一种场景，其中编译器4700确定功能的有效载荷4702(例如，“准备好执行的”数据数组)，并且在编译时将该有效载荷4702置于调用栈4704上。如将更详细地讨论的，功能能够经由有效载荷4702被调用为一个或多个本地实例4706(例如，在本地平台上)或一个或多个远程实例4708(例如，在远程平台上)。如果在运行时(例如，基于在编译时不知晓的各种条件)确定功能要在远程平台上被调用，则所例示的有效载荷4702被传输到远程平台上的调用栈4710，在那里有效载荷被通用rpc处置器使用来调用实例4708。在一个示例中，有效载荷4702包括一个或多个参数值、有效载荷4702的大小、以及功能的标识符。因此，所例示的解决方案消除了与功能参数的低效编组相关联的瓶颈。相应地，可以达成增强的性能、最少的管理和更大的可缩放性。

更具体地，“准备好传输的”格式可以被用作用于功能调用的abi(应用二进制接口)的一部分，其中用于调用的存根侧部分的栈4704包含使用rpc传输机制来传送到硬件或将其传递到硬件所要求的全部细节。因而，栈4704是有效载荷4702作为准备好执行的数据数组被放置的位置，从而使得它准备好目标的调用。因而，如果目标是远程的且需要经由非共享存储器传输机制来被调用，则目标通过已经堆叠在本地平台的栈4704上的有效载荷4702被直接调用。

在远程平台(例如，接收方/目标侧)上，反向操作类似地设置用于调用的栈4710(例如，将协议处理和数据拆包折叠成单个操作)。因而，如果目标是在不必通过线缆传输有效载荷的情况下能够被调用的远程过程，则能够在共享存储器中构建栈4704，并且在所有自变量以及用于指派远程调用的栈4704都在共享存储器中的情况下，rpc能够极度轻量，甚至匹配本地功能调用。

下文通过一个特意简单的示例来例示原理，其中编组涉及将参数值(例如自变量)简单地复制到栈帧内。对于更复杂的自变量，核心原理保持不变。

在运行时，取决于配置，诸如举例来说test(inta,shortb)之类的功能可以被指派为本地调用或远程网络主机上的远程调用。这一决策可以基于在编译时不知晓的各种条件来断言。在此类情形中，常规运行时可能如下执行此类调用(通过双斜杠后面的代码注释)：

if(__local_call_to_test()){

test(a,b)；//编译器生成将a和b如下放置

//在栈或寄存器上的代码，

//stack.a＝a；

//stack.b＝b；

//调用测试

}//使用常规abi，a和b将在栈和/或寄存器上

else{//用于test(a,b)的客户端侧存根

//构造用于发送的消息

structm_testm＝malloc(sizeof(structm_test))；

m->a＝a；

m->b＝b；

m->header＝...xxx...；

//经由传输执行调用

_rpc_call_(“test”,m)；

//目标主机将反转以上操作，并且接着在目标处调用test(a,b)

}

作为对比，本文描述的技术经由编译器4700来执行以下统一和简化。编译器4700对于对test(a,b)的调用将产生：

stack.header＝test_specific_header；//‘text’功能的标识，

//诸如可以是在v表中用于该功能的索引的32位或64位id

stack.a＝a；

stack.b＝b；

stack.epilogue＝test_specific_epilogue；//包含帧的大小，

//并且还可以包含其他内容。

//帧/有效载荷的大小启用通用rpc实现

call[test]；//使用v表(虚拟方法表)的间接调用

此外，如果调用是远程进程间通信(ipc)调用，则通用rpc处置器可以执行：

#define_sessizeof(stack.epilogue)//如头部中所定义的，使用作为有效载荷的栈内容以及有效载荷大小

//对该功能作出调用

send(stack.header.id,&stack-_ses_,_ses_)；

其中ses指栈尾大小(例如，用于代码简明的宏替换)。如已经提及的，有效载荷可包含被调用功能的标识、有效载荷的大小以及参数值(例如，避免原本会阻止跨域调用的任何指针/引用)。

图47b示出了高级架构4712，其中按照与本地调用在本地系统上执行相同的方式将远程调用布置成在其栈上进行指派。

现在转向图47c，示出了对功能参数进行编组的方法4720。方法4720可以被普遍地实现在增强的faas系统中，诸如举例来说已经讨论过的系统202(图2)、系统300(图3)、和/或系统400(图4)。更具体地，方法4620可作为一组逻辑指令被实现在一个或多个模块中，这组指令被存储在诸如ram、rom、prom、固件、闪存等的机器或计算机可读存储介质中，被存储在诸如例如pla、fpga、cpld的可配置逻辑中，存储在使用诸如例如asic、cmos或ttl技术的固定功能逻辑硬件或其任何组合中。

所例示的处理框4722提供了确定功能的有效载荷。在一个示例中，有效载荷包括一个或多个参数值、有效载荷的大小、以及功能的标识符。框4724在运行时将该有效载荷置于调用栈上，其中该功能能够经由该有效载荷被统一地调用为本地实例或远程实例。另外，框4726可以在运行时确定要将该功能调用为本地实例还是将该有效载荷传输到远程平台。因此，所例示的方法4720消除了与功能参数的低效编组相关联的瓶颈。相应地，可以达成增强的性能、最少的管理和更大的可缩放性。

因此，更高效的数据编组可涉及用可任选的位-阶(msb/lsb)和类型转码对数据结构的分散/收集。具体地关于可任选的位排序，在一些实现(例如在异构架构之间完成调用时，例如英特尔<->mips或arm)中，在多字节类型中指定字节顺序可能是重要的(例如，32位整数或浮点数)。例如，32位整数0x12345678可以被编码为以下字节序列：对于lsb(最低有效字节/位在前)而言是0x78、0x56、0x34、0x12或对于msb(最高有效字节/位在前)而言是0x12、0x34、0x56、0x78。相应地，接收方可能需要在加载时逆转该顺序，这在许多架构中是通过特殊指令来完成的。该技术还可以使用功能中枢来在基于cpu的参数传递以及远程调用或由加速器转移处置的调用之间进行转换。相应地，工作在其中进行的目标表现为完全就像是对调用方的进程本地调用。

附加注解与示例

示例4701包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算设备执行时致使该计算设备：确定功能的有效载荷，以及在编译时放置按照包含作出调用的足够信息的格式来将该有效载荷构建到调用栈上的代码，其中该功能能够经由该有效载荷被统一地调用为本地实例、远程实例或硬件。

示例4702包括示例4701的至少一种计算机可读存储介质，其中该有效载荷包括一个或多个参数值、有效载荷的大小、以及该功能的标识符。

示例4703包括示例4701的至少一种计算机可读存储介质，其中该指令在被执行时致使该计算设备：在运行时确定要将该功能调用为本地实例还是将该有效载荷传输到远程平台。

能力传递示例

在faas系统的操作期间，功能(例如，源功能)的能力常常被传递给可以是本地的(例如，与源功能共享存储器区域)或者远程的(例如，不与目的地功能共享存储器区域)另一功能(例如，目的地功能)。在功能相对无特权(例如，特权环3)时，安全措施是恰适的以确保在各功能之间传递的能力是合法的。如将更详细地讨论的，诸如图4中所示出的增强的faas系统之类的增强的faas系统所采用的增强的技术被用于减少对用于在复杂软件架构中生成功能能力的受信软件运行时的开发或插入的任何需要。此外，该技术消除了与在共享存储器设置中传递http消息和复制数据相关联的开销。

图48a示出了一种场景，其中第一功能4800(源功能“f3”)将能力信息4802结合对第二功能4806(目的地功能“f4”)的调用一起发送给受信队列管理器4804。在所例示的示例中，受信队列管理器4804确定能力信息4802相对于第一认证格式4808是否是有效的(例如，真实的)，其中能力信息4802和第一认证格式4808对应于第一功能4800。在实施例中，第一认证格式4808被第一功能4800识别，并且涉及受信队列管理器4804使用被指派给第一功能4800的第一密钥(未示出)来确定能力信息4802是否是有效的。更具体地，受信队列管理器4804可以将第一密钥与嵌入在能力信息4802中的消息认证码(mac)作比较。替换地，能力信息4802可以按照这样的方式被加密，以使得破坏能力信息4802不会为攻击者提供可预测且可用的功能性。

如果受信队列管理器4804确定能力信息4802相对于第一认证格式4808是有效的，则受信队列管理器4804将能力信息存储(例如，使其入列)到受信队列(未示出)。所例示的受信队列管理器4804还根据对应于第二功能4806的第二认证格式4810来生成能力信息4803并将其发送到第二功能4806。在实施例中，第二认证格式4810被第二功能4806识别，并且涉及用被指派给第二功能4806的第二密钥(未示出)来认证能力信息4803。在实施例中，认证包括使用第二密钥来重新计算mac并且将结果与嵌入在能力信息4803中的mac作比较。因而，第一认证格式4808通常与第二认证格式4810不同。

将受信队列管理器4804实现为硬件队列管理器(hqm)消除了对用于在复杂软件架构中生成能力信息4802、4803的受信软件运行时的任何需要。此外，受信队列管理器4804消除了与在共享存储器设置中传递消息(例如，以http格式或可以从f3被传递到f4的任何其他格式)和复制数据相关联的开销。功能4800、4806可以是便携式功能(例如，具有便携式身份)，以致于负载均衡器贯穿整个faas系统来动态地移动功能4800、4806。

图48b示出了经编码的内联能力(eic)信息4812(4812a-4812c)，其可以被容易地替换为已经讨论过的能力信息4802、4803(图48a)。在所例示的示例中，eic信息4812包括mac4812a、边界信息4812b和指针4812c。在一个示例中，mac4812a是由键控单向散列函数基于边界信息4812b创建的标签，其中被用于创建mac4812a的密钥位于(例如主机处理器上的)受保护区域中。因此，mac4812a被用于确认eic信息4812来自所声称的发送方且没有被改变。相应地，所例示的mac4812a通过使得也拥有密钥的验证方能够检测对eic信息4812的任何改变来保护eic信息4812的完整性和真实性。在一个示例中，指针4812c引用由边界信息4812b定义的存储器区域。因而，当功能尝试存储器访问时，检查mac4812a以确保在该访问中使用的指针是合法的且在由边界信息4812b定义的存储器区域内。

在实施例中，eic信息4812包括分层编码的内联能力。例如，复合eic可包括eic的子组，eic的子组进而对应于多级分层结构中的虚拟(例如，多播)通道。另外，eic信息4812可包括用户级中断(uli)作为能力，并且进程地址空间标识符(pasid)可以与eic信息4812一起入列。

图48c示出了硬件队列管理器4814，其可以被容易地替换为已经讨论过的受信队列管理器4804(图48a)。在所例示的示例中，硬件队列管理器4814维持队列集4816，其中每一队列4816持有用于特定功能或功能集的功能信息。所例示的解决方案因此通过使用对入列能力的硬件管理来实施虚拟通道。具有系统级特权(例如，超过环3的特权)的硬件队列管理器4814还可以与远程硬件队列管理器4820(例如，跨越另一平台/机器中的边缘)交换密钥信息4818。在实施例中，硬件队列管理器4814还承担更新其他上下文信息的责任，诸如举例来说用于认证能力的密钥、指示用于每一功能的专用数据区域边界的范围寄存器等等。硬件队列管理器4814因此表示对于驻留在环3中的常规根保护域(pd)4815的效率提升且充当用于生成功能能力的受信软件运行时。例如，一些常规根pd可以被实现为具有对进程内的所有存储器的访问权的无特权软件(例如，在cpu的环3中或在处理器上的另一无特权模式中)。该软件负责初始化专用数据区域边界寄存器，初始化能力认证密钥寄存器，以及生成经编码的内联能力，经编码的内联能力引用共享数据区域中特定非根pd被授权访问的存储器区域，这使得效率降级。在一个示例中，当前实施例的硬件队列管理器4814位于主机处理器(例如，cpu)中，其检测何时要由于不同功能的调用而发生上下文切换。

图48d示出了操作硬件队列管理器的方法4822。方法4822可以一般地由队列管理器来实现，该队列管理器诸如举例来说已经讨论过的受信队列管理器4804(图48a)和/或硬件队列管理器4814(图48c)。更具体地，方法4822可以被实现为存储在诸如ram、rom、prom、固件、闪存等非瞬态机器可读或计算机可读存储介质中的一组逻辑指令中的一个或多个模块，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能硬件逻辑中，或被实现为以上任何组合。

所例示的处理框4824确定能力信息相对于第一认证格式是否有效/真实，其中该能力信息和第一认证格式对应于第一功能。在一个示例中，框4824使用与第一功能相关联的第一密钥来确定该能力信息是否有效。如果是，则框4826将该能力信息存储(例如，使其入列)到受信队列。在一个示例中，该能力信息包括分层编码的内联能力。

在框4828，根据对应于第二功能的第二认证格式，该能力信息被传递到第二功能。在实施例中，第二认证格式指定对与第二功能相关联的第二密钥的使用以在到第二功能的传输期间保护并认证该能力信息。在示例中，第一功能和第二功能是便携式功能。所例示的方法4822因此减少了对用于在复杂软件架构中生成功能能力的受信软件运行时的任何需要。此外，该技术消除了与在共享存储器设置中传递消息和复制数据相关联的开销。

图48e示出了根据实施例的使能力入列的方法4830。方法4830可以一般地由队列管理器来实现，该队列管理器诸如举例来说已经讨论过的受信队列管理器4804(图48a)和/或硬件队列管理器4814(图48c)。更具体地，方法4830可以被实现为存储在诸如ram、rom、prom、固件、闪存等非瞬态机器可读或计算机可读存储介质中的一组逻辑指令中的一个或多个模块，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能硬件逻辑中，或被实现为以上任何组合。

所例示的处理框4832检测使用新指令(例如，enqcap)来使能力入列的一个或多个服务请求，该一个或多个服务请求指定要被发送的能力及其预期目的地。例如，目的地可以被指定为全局唯一的或局部唯一的服务id。在所例示的框4834，enqcap使用当前能力认证密钥来认证所提供的能力。如果认证成功，则enqcap框4836从能力中提取边界和指针信息。enqcap框4838接着标识用于所提取的信息的恰适目的地队列。例如，该过程可涉及将服务id转换成已经被分配用于主存服务的处理器的id。每一服务可以被锁定到一个或多个处理器，或者在系统中的任何处理器上调用服务是可能的。甚至在不同的系统中的处理器上自动调用服务也是可能的。此类调用会要求将能力所引用的数据复制到目的地系统。这还可能要求将用于服务的代码复制到目的地系统。

可以要求用于与目的地系统进行通信的网络协议。例如，操作系统可负责在不同系统上的硬件队列管理器实例之间建立连接性。硬件队列管理器接着可彼此通信。所例示的框4840使指针和边界信息连同目的地服务id一起入列到目的地队列中。接着可以在框4842处继续服务执行。如果在框4834确定所提供的能力不是真实的，则在所例示的框4844生成异常。

图48f示出了根据实施例的使能力出列的方法4831。方法4831可以一般地由队列管理器来实现，该队列管理器诸如举例来说已经讨论过的受信队列管理器4804(图48a)和/或硬件队列管理器4814(图48c)。更具体地，方法4831可以被实现为存储在诸如ram、rom、prom、固件、闪存等非瞬态机器可读或计算机可读存储介质中的一组逻辑指令中的一个或多个模块，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能硬件逻辑中，或被实现为以上任何组合。

所例示的处理框4833检测用于使指针和边界信息以及目的地服务id出列的请求。可以在框4835作出关于目的地服务当前是否被加载的确定。如果否，则框4837加载用于目的地服务的代码和数据并且分配专用数据区域。另外，在框4839初始化专用数据区域边界寄存器以覆盖用于目的地服务的专用数据区域。在实施例中，框4841用随机生成的数据来初始化能力认证密钥寄存器。在生成经编码的(例如，加密的)内联能力和/或消息中的mac时，认证密钥寄存器中的密钥被用作输入。由于非根pd无法读取或访问该密钥，因此对该密钥的使用有助于防止非根pd具备锻造能力。所例示的框4843生成表示出列的指针和边界信息的经编码的内联能力，并且将所生成的eic存储在寄存器中以使得目的地服务能够访问它。框4845向目的地服务传递控制。如果在框4835确定目的地服务当前被加载，则方法4831可以绕过框4837。

附加注解与示例

示例4801包括一种半导体装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑被至少部分地实现在可配置逻辑或固定功能硬件逻辑中，被耦合至该一个或多个衬底的该逻辑用于：确定能力信息相对于第一认证格式是否有效，其中该能力信息和第一认证格式对应于第一功能，在该能力信息相对于第一认证格式有效的情况下将该能力信息存储到队列，以及根据对应于第二功能的第二认证格式将该能力信息传递到第二功能，其中第一功能和第二功能是便携式功能，并且其中该能力信息包括分层编码的内联能力和用户级中断。

示例4802包括一种半导体装置，其包括：一个或多个衬底、以及耦合至该一个或多个衬底的逻辑，其中该逻辑被至少部分地实现在可配置逻辑或固定功能硬件逻辑中，被耦合至该一个或多个衬底的该逻辑用于：确定与要被执行的功能相关联的出列指针和边界信息和目的地服务id，响应于目的地服务当前未被加载，为所标识的目的地服务加载与该功能相关联的代码和数据并且分配用于执行该功能的专用数据区域，以及向所标识的目的地服务传递控制，其中分配用于执行该功能的专用数据区域包括初始化一个或多个专用数据区域边界寄存器以覆盖用于目的地服务的专用数据区域，用随机生成的数据来初始化能力认证密钥寄存器，生成表示出列的指针和边界信息的经编码的内联能力，以及将经编码的内联能力存储在寄存器中以供目的地服务访问。

地址空间内分区示例

完全存储器加密(tme)可以用单个密钥对平台的整个存储器(例如，各个高速缓存级)进行加密。tme可以通过bios配置和/或其他软件来启用，并且可以有助于确保存储器中的所有数据(例如，消费者凭证、加密密钥、以及其他ip或个人信息)在外部存储器总线上被加密。因而，如果应用和/或cpu向存储器请求数据，则该数据可以被加密并且接着稍后在传输之后被解密。

用于存储器加密的加密密钥可以使用cpu和/或受信平台管理器中的加强随机数生成器来生成。在一些实施例中，该密钥可能永远不被暴露于软件，藉此降低恶意数据盗窃和/或密钥使用的交叉污染的可能。在其他实施例中，软件可以能够通过密钥id来访问密钥。

存储器中的数据以及外部存储器总线上的数据可以被加密，并且在cpu内部时和/或由受信平台管理器(tpm)被解密成明文，类似于典型的存储加密。这允许在使用tme保护存储器的同时现有软件无修改地运行。tme可以被调整为仅加密存储器的一部分(例如，特定物理地址范围)，而使存储器的另一部分(例如，另一物理地址范围)保持未加密。在具备tme能力的系统上运行的软件可以读取cpu中的配置寄存器以具备对于存储器中被配置成不要被tme加密的未加密部分的完全可见性。

多密钥tme(mk-tme)将tme扩展为支持多个加密密钥以提供指定将特定密钥仅用于存储器的一部分(例如，页和/或物理地址范围)的能力。mk-tme允许本地生成的密钥(例如，tpm生成的密钥和/或cpu生成的密钥)和/或第三方密钥(例如，租户提供的、在远程位置处脱离平台生成的密钥)，从而向消费者提供全面的灵活性。由此，存储器可以根据多个加密密钥被加密。因此，第一地址范围可以根据第一密钥被加密，而第二地址范围可以根据第二密钥被加密。

mk-tme允许用单独的加密密钥使虚拟机(vm)和容器在存储器中密码地彼此隔离。在多租户云环境中，在敏感数据正被消费者处理时此类隔离是有利的。

vm和容器可以在某些情况下被授权共享个体密钥，从而进一步扩展规模和灵活性。例如，如果第一faas功能调用第二faas功能，则第一和第二功能两者均可被允许访问相同的数据。在另一示例中，相同的消费者可以调用两个功能，其中一个功能生成数据而另一功能消费所生成的数据。这两个功能可以被允许共享密钥，如上所述。

因而，mk-tme可以被用于通过用不同的加密密钥对被指派给每一功能的存储器区域进行加密来使各个功能彼此隔离/分开。此类办法降低了将各个功能指派到具有单独页表的单独线性地址空间的任何需要，这原本会引起调用os内核、切换页表、以及重填充转换后备缓冲器(tlb，其存储虚拟存储器到物理存储器的最近转换)的开销。尽然以下的描述是参照各个功能通过密钥来访问数据进行描述的，但可以理解的是，各个功能可以结合底层硬件(例如，cpu或tpm)来操作以解密数据。例如，功能可以按照这样的方式执行，以使得cpu和/或处理器从存储器检取数据，并且解密该数据，藉此允许该功能访问该数据。

图49a示出了密钥标识符(id)集4900(4900a-4900d)和被用于对共享线性地址范围中的存储器区域进行加密的加密密钥集4902(4902a-4902f)之间的映射。在所例示的示例中，第一密钥id4900a被指派给第一密钥4902a和第二密钥4902b，第二密钥id4900b映射到第三密钥4902c，第三密钥id4900c映射到第四密钥4902d和第五密钥4902e，并且第四密钥id4900d映射到第六密钥4902f。因此，所例示的映射使得密钥id4900能够跨密钥4902被重用。例如，如果对应于第一密钥4902a的功能终止或用第一密钥4902a加密的存储器区域以其他方式被释放，则第一密钥id4900a可以被自动地重指派到第二密钥4902b而无需切换页表。

图49b示出了单个地址空间4901的示例，其中密钥id(kid)复用不限于专用区域的密钥和密钥id。在所例示的示例中，kid1映射到功能f1和f3中的k7，kid2映射到功能f2中的k9，并且kid3映射到功能f4中的k9。后两个映射例示了单个底层密钥能够从多个密钥id来映射，这在图49a中可能不是显而易见的。

图49c示出了示例，其中第一功能4904使用(例如，从其读取和/或向其写入)用第四密钥4902d加密的第一存储器区域4906。在所例示的示例中，第三密钥id4900c最初被指派到第四密钥4902d。在发生从第一功能4904到第二功能4908的上下文切换时，第三密钥id4900c被自动重指派到第五密钥4902e，第五密钥4902e被用于对与第二功能4908相关联的第二存储器区域4910进行加密。尤其值得注意的是，第一存储器区域4906和第二存储器区域4910位于共享线性地址范围4912中。相应地，所例示的解决方案消除了调用os内核、切换页表、以及重填充具有虚拟存储器到物理存储器的转换的tlb的开销。所例示的存储器区域4906、4910也可以根据被用于对共享存储器区域进行加密的密钥(分别为“k9”和“k7”)来加密。

更具体地，需要经由共享存储器进行通信的功能应当共享对用于对共享存储器的对应区域进行加密的密钥的访问。例如，如果功能f1和f3需要通过共享存储器区域4910来通信，则该区域可以使用k7加密，且每一功能中的某一密钥id可以被映射到k7。该密钥id在两个功能中可以是相同的，或者其可以是不同的。重要的是，这两个功能都能够使用k7。然而，使两个功能使用相同的密钥id可能存在某些优点，因为密钥id可以经由物理地址位来传达。共享密钥id使得使仅单个线性到物理地址映射覆盖在f1与f2之间共享的存储器区域变得容易。与使多个线性到物理地址映射覆盖该区域以支持不同密钥id相比，此类办法降低了tlb开销。

例如，可以定义新类型的指令以将密钥id切换为映射到不同的密钥。该指令类型可被限于仅能在特定代码范围(例如，使用范围寄存器来定义)内使用。该范围可以被配置成对应于根pd代码。该指令可以准许从由特权软件(例如，os或vmm)和/或硬件(例如，cpu或tpm)配置的密钥储存库中选择密钥。替换地，该指令可以将软件提供的密钥记录到对于特权软件已知但无特权软件不可访问的位置中的结构中。处理器可以被配置成从该结构检取用于每一功能的当前密钥id到密钥的映射。例如，这可以在每一次新功能被调用时发生，或者根pd可以调用指令以致使处理器基于存储器内结构的内容来更新其内部状态。

替换地，可以定义指令来改变负责映射单个虚拟地址或虚拟地址范围的一个或多个叶页表条目中的密钥id。

显而易见的是，每一功能可以使用多个密钥id来访问存储器。为了为每一次存储器访问选择恰适的密钥id，功能可以在每一虚拟存储器地址中指定标签值，并且该标签值可以被映射到物理存储器地址中的对应密钥id。例如，图49f例示了在虚拟地址4932与物理地址4936之间进行映射的tlb/页未命中处置器4394。tlb/页未命中处置器4394可以是处理器的一部分。虚拟地址4932的标签值被用于引用线性地址位片中的值，诸如可以以某种方式被映射到“密钥id”值的物理地址4936。“密钥id”被用于引用物理地址位片中可以以某种方式(例如，通过对照密钥id引用的查找表)被映射到密钥的值。页表条目可指定物理地址。在所例示的实施例中，tlb/页未命中处置器4934将虚拟地址4932转换成物理地址4936，并且除了转换标签值之外在转换期间可以忽略标签值。标签值接着可以从虚拟地址4932中被提取并被插入物理地址4936中。因而，处理器可以提取指定标签并将标签插入指定密钥id的物理地址片的虚拟地址位片，如图49f所示。

再次参考图49e，用于根pd的专用数据区域可以使用单独密钥来加密以防止对抗功能访问专用数据区域的明文内容。来自功能内的可用密钥id不会映射到该密钥。

用于每一功能和根pd的代码可以使用单独密钥来加密，并且密钥id到密钥的映射可以被配置成通过仅准予每一功能访问用于其自身专用代码区域的密钥来帮助防止(例如，直接在各个功能之间或从功能到根pd中未经授权的进入点)未经授权的控制流传递。可以采用蹦床，其可包括经由到代码中的第一位置的跳转达到代码中的第二位置的进程。在根pd与功能之间传递控制时更新密钥id到密钥的映射的蹦床代码段可以使用从所有功能和根pd都可访问的密钥id映射的密钥来加密。替换地，该蹦床代码段可以针对每一功能被重复，以使得每一功能仅需要使用单个密钥来加密在该功能的上下文中执行的所有代码，包括蹦床代码。

替换地，用于所有功能和根pd的代码可以使用单个、共享密钥来加密，并且各种控制流完整性实施机制可以被应用以防止未经授权的控制流传递。例如，16/024,547描述了一些可能的机制。

图49d示出了单个地址空间4915，其包含根保护域4914(pd，例如，位于主机处理器/cpu中的用户空间受信监视器)、多个每服务专用数据区域4917、以及具有多个通信缓冲器的共享数据区域4916。在所例示的示例中，每一每服务专用数据区域使用不同的密钥(例如，k*)来加密。在实施例中，根pd4914在各个功能之间切换时执行映射更新以避免调用内核的开销。因而，所例示的根pd4914将不同的密钥id指派到不同密钥以使密钥id重指派的频率最小化。更具体地，在目的地密钥id已经被映射到用于目的地功能的密钥的情况下，根pd4914可以切换到具有与当前功能不同的密钥id的功能。可以从多个功能访问一些密钥id以实现共享存储器通信。

图49e示出了更新密钥id映射的方法4918。方法4918可以一般地由根pd来实现，诸如举例来说已经讨论过的根pd4914(图49d)。更具体地，方法4918可以被实现为存储在诸如ram、rom、prom、固件、闪存等非瞬态机器可读或计算机可读存储介质中的一组逻辑指令中的一个或多个模块，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能硬件逻辑中，或被实现为以上任何组合。

所例示的处理框4920提供了将密钥标识符映射到第一密钥，其中第一密钥与第一功能以及用第一密钥加密的第一存储器区域相关联。在框4922检测从第一功能到第二功能的上下文切换。另外，所例示的框4924响应于该上下文切换将该密钥标识符映射到第二密钥，其中第二密钥与第二功能以及用第二密钥加密的第二存储器区域相关联。在实施例中，第一存储器区域和第二存储器区域共享线性地址范围。因此，所例示的方法4918消除了调用os内核、切换页表、以及重填充具有虚拟存储器到物理存储器的转换的tlb的开销。

另外，第一密钥可以是用于第一目标域的对称密钥，而第二密钥可以是用于第二目标域的对称密钥。在一个示例中，第一目标域和/或第二目标域是信任域的子域。在此类情形中，除了加密密钥(其可以被称为“微调密钥”)的“微调”值可以被用于可微调密码，其实现要针对每一子域指定的不同密码输入(例如，除了常规密钥和明文或密文输入之外的微调)。使用微调密钥与为每一子域指定完全不同的密钥相比常常更高效。微调密钥可允许在无需在硬件中维护附加密钥的成本的情况下在信任域内有效地维护的单独的子信任域。由于子域总是在“外部”信任域的上下文中执行，并且两个子域在存储器地址空间中是互相排斥的，因此在将微调用于主信任域密钥以生成微调密钥时微调给予了附加的伪随机性。另外，在信任域被销毁时，主密钥也被销毁，这用于通过移除对任何微调密钥的访问权来同样有效地擦除所有子域内容。

在调用功能之前，可以通过使根pd将该功能未被授权使用的密钥与该功能可访问的任何密钥id逐一地解除映射来防止该功能访问那些密钥。然而，这可能引入不必要的执行开销。更高效的替换方案可以是支持将地址标签映射到密钥id的表以及支持用于在此类表之间进行切换的高效操作。这类似于页表，其将虚拟存储器地址映射到物理存储器地址。如果密钥映射表被存储在存储器中，这对于支持大量功能而言会是有益的，那么将从标签到密钥id的映射高速缓存在标签到密钥id后备缓冲器(tklb)中也是有益的，标签到密钥id后备缓冲器(tklb)类似于用于高速缓存虚拟到物理地址映射的转换后备缓冲器(tlb)。类似于可如何用地址空间标识符(asid)对tlb条目加标签以使在不同地址空间之间进行切换时转储清除它们的需要最小化，tklb条目也可以用分区id被加标签。例如，分区id可以被存储在仅能从根pd访问的寄存器中。

作为标签到密钥id映射表的替换或附加，可以定义阻塞功能对特定标签值或密钥id的访问的机制/过程。例如，位掩码可以被存储在仅能从根pd访问的寄存器或存储器中的位图中。在调用每一功能之前，根pd可以更新该标签掩码结构以指示该功能被授权使用的标签或密钥id。例如，标签掩码结构中的设置位可指示与该位位置相对应的特定标签或密钥id被授权供该功能使用。可以定义单独的标签掩码结构以规定代码取得和数据访问(例如，以实施仅执行存储器许可)。甚至可以通过针对每一访问类型定义的单独标签掩码结构将数据访问进一步细分为读、写等。

还可以对照标签掩码结构来检查对改变页表条目中的标签值的指令的调用以确保新功能被授权使用原始标签值和新标签值两者。该指令可以接受标签掩码结构应当被检查或者它们可以全都被并行地检查的指定符。

为进一步降低执行开销，使功能能够丢弃对指定标签的访问权可能是有益的。例如，可以定义仅支持清除标签掩码结构中的位的指令。这一办法可以使得功能能够在调用子分区之前丢弃对某些标签的访问权以通过阻止该功能访问与被丢弃的标签相关联的存储器区域来有效地沙箱化该子分区。该子分区会被防止自身重新启用对该标签的访问。

根pd可以被调用以重新添加对当前被标签掩码结构阻塞的标签值的访问。替换地，可以用标签掩码结构值来扩展调用门以在穿过每一门时应用该标签掩码结构值。

丢弃对标签值的访问的功能对于在即时(jit)编译器中实施仅执行存储器许可而言可以是有用的，因为jit可以将代码写入存储器并且接着从数据标签掩码结构中丢弃对应的标签同时仍然使其在代码标签掩码结构中被启用。

此外，硬件可以可任选地实施阻止对非根保护域内的可执行存储器进行写入的策略。在针对所有标签值或针对特定标签值启用时，可以在取得具有对其启用了该策略的标签值之一的指令时检查数据写入标签掩码结构和代码取得标签掩码结构两者。如果取得标签掩码结构阻塞对对应标签的访问或者如果数据写入标签掩码结构允许对对应标签的访问，则可以阻塞该取得。

在一些应用中放弃虚拟地址位来指定标签可能是不期望的。替换地，每一存储器访问的有效段可以被用于选择标签或密钥id。例如，代码取得可以使用与代码段(cs)相关联的标签，正常数据访问将使用与数据段(ds)相关联的标签，而栈访问将使用与栈段相关联的标签。标签关联可以仅基于有效段(例如，cs相对于ds)、相关段选择器值、或段寄存器内包含的(例如，从段描述符表条目加载的)其他信息。段到标签的关联可以被存储在寄存器或存储器内的表中。关联数据可以仅能够由特权软件更新，或者也能够由经授权的无特权软件更新。例如，可以定义用于更新那些关联的指令，并且该指令的使用可被限于根pd的代码范围。

附加注解与示例

示例4901包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算系统执行时致使该计算系统：将密钥标识符映射到第一密钥，其中第一密钥与第一功能以及用第一密钥加密的第一存储器区域相关联，检测从第一功能到第二功能的上下文切换，以及响应于该上下文切换来将该密钥标识符映射到第二密钥，其中第二密钥与第二功能以及用第二密钥加密的第二存储器区域相关联，其中第一存储器区域和第二存储器区域在相同地址空间中，其中第一密钥是用于第一目标域的密钥而第二密钥是用于第二目标域的密钥，并且其中第一目标域或第二目标域中的一者或多者是信任域的子域。

无特权保护密钥更新示例

图50a示出了启用要针对多个功能指定的访问许可的多个服务保护域5000(5000a-5000n)。更具体地，所例示的域5000对应于保护密钥寄存器(pkr，未示出)中的多个“片”，其中每一片包含用于禁用对页(例如，存储器区域)的所有访问的位以及用于禁用对该页的写入的位。根保护域(pd)5002(例如，受信用户空间监视器)一般地调度功能用于执行，并且将每一被调度的功能指派到域5000之一(例如，以及保护密钥寄存器中的片中的一个片)。因而，根pd5002可以将第一功能指派到第一域5000a(例如，以及pkr中的第一片)，将第二功能指派到第二域5000b(例如，以及pkr中的第二片)，并且以此类推。一些功能可以被分配对多个片的访问(例如，在片中的一个片规定了对存储器中在多个功能之间共享的区域的访问的情况下)。

所例示的根pd5002还将保护密钥id指派到被调度的功能，其中每一保护密钥id映射到加密密钥，该加密密钥被用于对该功能将访问的页进行加密。在根pd5002调度功能以用于执行时，根pd5002确定保护密钥id是否可用于被指派给该功能。就此，功能的数目可能大于保护密钥id的数目(例如，所例示的示例中的“n”)。如果没有保护密钥可用于被指派给该功能，则保护密钥id的数目相对于全部功能的集合而言是不足的。在此类情形中，所例示的根pd5002向主机处理器(例如，cpu，未示出)发出更新指令5004。更新指令5004指令主机处理器用新保护密钥id(pkid新)来更新分层页表5008中的条目5006。就此，更新指令5004可以指示什么值要用于新保护密钥id以及页的线性地址。因而，主机处理器可以使用该线性地址来定位(例如，经由页遍历)分层页表5008中的条目5006。页表5008中的条目是受保护以免于无特权组件的直接修改的特权数据结构。因此，所例示的办法仅准许保护密钥id信息被修改。

在实施例中，更新指令5004还指令主机处理器清除分页结构高速缓存。此类办法确保陈旧的保护密钥id值从分页结构高速缓存中被移除。另外，更新指令5004可以指令主机处理器清除tlb(未示出)，tlb存储虚拟存储器地址到物理存储器地址的最近转换，如已经提及的。因此，所例示的解决方案消除了在用新保护密钥id来更新页表5008时调用os内核的任何需要。

可以通过限制对更新指令5004的访问来解决其他安全问题。在一个示例中，各个功能限于托管运行时功能。一般来说，托管运行时环境可以是高级解决方案，诸如举例来说，html5(超文本标记语言5，例如html5编辑者草案，2012年5月8日，w3c)、dalvik(安卓开放手持机联盟/oha)、art(安卓运行时，oha)、c#(例如，c#5.0，微软公司，2012年8月15日)、.net(例如，.net框架4.5，微软公司，2013年10月17日)、ruby(例如，ruby2.1.0，y.松本，2013年12月25日)、perl(例如，perl5.18.2，perl.org，2014年1月7日)、python(例如，python3.3.3，python软件基金会，2013年11月19日)、java(例如，java标准版7更新51，甲骨文公司，2014年1月14日)等。因而，因为各个功能由托管运行时环境即时(jit)解读或调用，增强了安全。

另外，可以实施功能的原子执行。因此，此类办法保护在操作中的线程免于被挂起，这在操纵它们自身的线程的应用(例如，数据库、java和/或垃圾收集应用)中可能会发生。

限制对更新指令5004的访问的其他办法包括：扫描非受信代码以验证它不包含更新指令5004，阻塞用于在包含根pd5002的指定区域外部执行更新指令5004的任何尝试等等。

图50b示出了更新保护密钥id的方法5010。方法5010可以一般地由根pd来实现，诸如举例来说已经讨论过的根pd5002(图50a)。更具体地，方法5010可以被实现为存储在诸如ram、rom、prom、固件、闪存等非瞬态机器可读或计算机可读存储介质中的一组逻辑指令中的一个或多个模块，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能硬件逻辑中，或被实现为以上任何组合。

所例示的处理框5012提供了检测相对于功能集的数目不足的保护密钥id。框5014响应于数目不足的保护密钥id来指令处理器(诸如举例来说主机处理器)用新保护密钥id来更新页表条目。因此，框5014可包括发出指示新保护密钥id和线性地址的更新指令，其中处理器基于该线性地址执行对分层页表的页遍历。所例示的框5014还指令(例如，经由更新指令)处理器清除分页结构高速缓存和tlb。在一个示例中，功能集限于托管运行时功能以限制对更新指令的未经授权的访问。在实施例中，框5014还更新用于被分配到特定服务的所有页的页表条目(pte)，因为每一服务可能具有不止一个页。框5014还可包括：实施功能的原子执行，扫描非受信代码以验证其不包含更新指令，阻塞用于在包含根pd的指定区域外部执行更新指令的任何尝试等。因此，所例示的方法5010消除了在更新页表条目时调用os内核的任何需要。

附加注解与示例

示例5001包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算系统执行时致使该计算系统：检测相对于功能集的数目不足的保护密钥标识符，响应于该数目不足的保护密钥标识符来指令主机处理器更新页表条目，其中功能集限于被管理的运行时功能，以及实施功能集的原子执行。

示例5002包括示例5001的至少一种计算机可读存储介质，其中该可执行程序指令在被执行时进一步致使该计算系统：指令主机处理器清除分页结构高速缓存。

示例5003包括示例5001的至少一种计算机可读存储介质，其中该可执行程序指令在被执行时致使该计算系统：指令主机处理器清除转换后备缓冲器。

去特权页表许可更新示例

图51a示出了进程5100，其包括沙箱5102(例如，作为代码隔离工具来操作的规则集)，其中沙箱5102限制无特权组件(诸如举例来说，用户模式中介5104(例如，用户空间分区管理器))访问“被置于沙箱中”的资源(诸如举例来说，逻辑地址空间5106中的逻辑块地址5112以及物理地址空间5110中的物理页5114)。用户模式沙箱化操作常规地可经由面向软件的访问控制来实施。在所例示的示例中，指令集架构页表(isa-pt)5108将逻辑地址空间5106映射到物理地址空间5110，并且在页地址转换未命中tlb(未示出)时cpu5118的页未命中处置器(pmh)5116执行地址转换。通过硬件来加强基于软件的访问控制对于“侧信道攻击”可能是特别有利的，“侧信道攻击”在多租户工作负载共享逻辑地址空间5106且cpu5118是使用推测性执行的乱序(ooo)处理器时可能发生。

具体地关于乱序处理，cpu完成某些指令并且开始执行其他指令，即便这些指令在稍后将被发现已经不被允许，因此那些指令中没有一条指令有资格实际引退。因而，不被允许的指令的结果中没有一个结果实际上修改了任何变量。侧信道攻击风险可以以观察到源自攻击者知道被禁止但仍然如此精心构造的操作的性能影响的形式来出现。因而，即便攻击者无法访问位置x，但由于ooo而能够临时取得重大进展以从位置x处的几个位中构造值v(例如，通过*x和0x0f)，攻击者接着可以访问某一其他可许可范围，诸如举例来说r[v]。在稍后攻击者通过检查等待时间能够检查对处于v的不同可能值的r[…]的访问会产生高速缓存命中还是未命中时，对r[v]的访问会导致性能差异。以此方式，攻击者一次学习几位位置x处的内容，而实际上不被允许直接查看那些内容。

faas工作负载可以是服务器形式的多租户工作负载，其同样能够获益于经由硬件实施的更精细粒度的访问控制。更具体地，faas能够获益于硬件以更精细粒度的存储器对象级别来提供访问控制，而常规硬件可能将存储器许可限于4096字节(4kb)级别(例如，页级)。

所例示的解决方案提供了子页许可模型，子页许可模型是硬件实施的并且使得os5120能够将精细粒度的许可管理和更新委托给用户模式中介5104。因而，多租户工作负载可以与管理分区许可的用户模式中介5104在相同的逻辑地址空间5106中运行。然而，值得注意的是，os5120继续控制线性地址空间5106到物理地址空间5110的映射。

一般来说，保护密钥使得能够以稀疏的方式跨进程5100内的多个子域(例如，16个子域)来划分逻辑地址空间5106。常规的保护密钥可允许在每域的基础上表达针对页的读/写(rw)许可，以及在不进行系统调用的情况下在域之间的快速切换。

在所例示的示例中，子页许可表(sppt)5122按照子页级别5125(例如对于4kb页而言是128字节粒度)来指定许可，并且被暴露于用户模式中介5104。所例示的用户模式中介5104对于sppt5122具有读/写/执行(rwx)特权。在一个示例中，用户模式中介5104能够缩减关于物理地址空间5110中的子页的子页许可(例如，使rw访问权降级为只读访问权)，但是不具备使子页许可增长的能力(例如，将只读访问权升级为读/写访问权)。

因此，经由sppt5122对物理地址空间5110中的每一物理页5124(或虚拟化环境中的客物理地址/gpa)实施子页许可。在实施例中，sppt5122将物理页5124映射到许可的位向量，其中每一位对应于子页区域的写许可。代替仅在扩展页表(ept)页条目指定针对特定4kb映射启用子页许可时由cpu5118对sppt5122进行遍历，所例示的解决方案将页遍历改变为1)完成isa-pt5108页遍历，将逻辑块地址5126转换成物理页5124的地址，以及接着使用物理页5124的地址来遍历sppt5122。因而，子页许可由isa-pt5108启用/触发，但不要求虚拟机监视器(vmm)来启用ept。

另外，sppt5122通过isa-pt5108中由os5120为用户模式中介5104创建的恰适映射被暴露于用户模式中介5104。这些映射准许用户模式中介5104自由地修改许可，但是不能修改针对页的逻辑块地址到物理地址的映射，这仍然由os5120来控制。

此外，用户模式中介5104可以使用新指令来无效sppt5122，其中该新指令转储清除被高速缓存的许可。在许可被减少时，此类办法尤其有用。在进程上下文切换之际用户模式中介5104被跨cpu迁移的情况下/时，任何被高速缓存的许可也可以被转储清除。在一个示例中，子页许可在每安全域的基础上被暴露于高级程序语言。另外，调用栈区域可以被用于将被调用的功能与调用方功能隔离开(例如，以防止来自具有相对较低特权的被调用功能的反向栈攻击)。

图51b示出了控制子页许可的方法5128。方法5128可以一般地由os来实现，诸如举例来说已经讨论过的os5120(图51a)。在实施例中，方法5128被实现为被存储在诸如ram、rom、prom、固件、闪存等非瞬态机器可读或计算机可读存储介质中的一组逻辑指令中的一个或多个模块，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能硬件逻辑中，或被实现为以上任何组合。

所例示的处理框5130提供了阻止无特权组件(例如，用户模式中介)修改由多个功能共享的、逻辑地址空间与物理地址空间之间的映射。在框5132，无特权组件被准许缩减关于物理地址空间的子页许可。

在一个示例中，框5134在每安全域的基础上将子页许可暴露于高级程序语言。就此，子页许可可以作为标签或注释被暴露于某些安全域。

在实施例中，框5136经由调用栈区域将多个功能中的被调用功能与该多个功能中的调用方功能隔离开。因此，框5136防止其中被调用功能比调用方功能处于更低特权的反向栈攻击。框5130、5132、5134、5136是可以非顺序地和/或以任何合适的顺序执行的独立操作。

附加注解与示例

示例5101包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算系统执行时致使该计算系统：阻止无特权组件修改由多个功能共享的、逻辑地址空间与物理地址空间之间的映射，准许无特权组件缩减关于物理地址空间的子页许可，在每安全域的基础上将子页许可暴露于高级程序语言，以及经由调用栈区域将多个功能中的被调用功能与该多个功能中的调用方功能隔离开。

去特权模式示例

通常通过在各租户之间共享硬件计算资源(其示例是云计算、faas等)来达成对硬件利用和整体商业效率的提升。这种共享可能要求进程对各个动作定界，并且阻止跨租户工作负载交互以保护安全和隐私。因而，经定界的动作指的是需要预先被设定限制(例如，被包含)的任何事物，通常这种控制(containment)适用于通过某种隔离(诸如举例来说沙箱、虚拟机(vm)等)被“约束”的代码。

虽然vm、进程、名称空间(例如，对于“容器”而言)和被管理的运行时可以解决控制挑战，但在启动时间、调用性能和/或存储器开销方面仍然存在相当大的改进空间，从而限制了部署的适用性和密度。

诸如网络功能虚拟化(nfv)的一些应用可能要求纳秒至微秒范围内的等待时间，而常规faas实现在调用冷启动容器时可能会引起数十毫秒上下的等待时间。通常在此类应用中使用的轮询模式具有另一组问题，与隔离相关联的密度和存储器开销。实际上，vm和容器可能仍然使用相对大量的存储器，从几mb到几gb。相应地，服务器上的实例量通常是受限的。此外，轮询模式执行对于过度订阅可能无法很好地起作用。作为对比，运行直到完成的办法通常(例如，由于功能调用之间的共享存储器空间导致的)仅在单个应用内适用，或者在被映射到具有良好隔离的faas模型的情况下会具有高等待时间。

在极端情形中，在所有应用被分解成既本地又远程地运行的功能(例如，包括os、平台和基础设施服务)时，对性能的需求可能达到每服务器每秒数亿次调用，而这常规来说仅能够经由本机代码和调用指令来达成。

被称为去特权模式的一种最近开发的技术提供了一种框架，该框架使功能在沙箱环境中运行同时共享由多个存储器“段”构成的地址空间。沙箱化防止功能改变段，并且限制在沙箱内包含由代码段定义的控制传递。本地描述符表(ldt)是包含存储器段描述符的存储器表。每一段描述符包括选择符(例如，索引)和各种属性，诸如举例来说，基址、大小、访问特权等。为了引用存储器段，功能将该选择符加载到段寄存器中，这致使描述符属性从ldt被传递到主机处理器中。对ldt的后续修改一般是无效的，除非段寄存器被重新加载。去特权模式办法依赖于对经修改的段描述符的使用，其中基址作为范围的下界来对待。然而，因为可用段描述符的数目受到限制，所以可能要求对ldt的动态更新。另外，较低数目的段寄存器仅允许受限数目的存储器范围被使用，从而对将所有参数和结果都置于连续的存储器区域中的调用方施加压力。

本文描述的技术将去特权模式扩展到能力信息(诸如举例来说，经编码的内联能力(eic)信息)，并且在共享地址空间的同时实现对多个存储器区域的使用。更具体地，实现去特权模式的配置以实施用于存储器访问的eic语义，定义用于eic的、覆盖栈访问的应用二进制接口(abi)，以及定义对来自去特权代码的系统/外部调用的处置。

图52a示出了用于尝试访问共享存储器(例如，存储器段)的功能的去特权模式路径5200。在所例示的示例中，对尝试的存储器访问实施eic信息5202(5202a-5202c)的一个或多个能力约束(例如，语义)。eic信息5202包括mac5202a、边界信息5202b、和指针5202c。在一个示例中，mac5202a是由键控单向散列函数基于边界信息5202b创建的标签，其中被用于创建mac5202a的密钥位于(例如，主机处理器上的)受保护区域中。因此，mac5202a被用于确认eic信息5202来自所声称的发送方且没有被改变。相应地，所例示的mac5202a通过使得也拥有密钥的验证方能够检测对eic信息5202的任何改变来保护eic信息5202的完整性和真实性。在一个示例中，指针5202c引用由边界信息5202b定义的存储器区域。因而，当去特权功能尝试存储器访问时，检查mac5202a以确保在该访问中使用的指针是合法的且在由边界信息5202b定义的存储器区域内。

在一个示例中，段描述符也被修改以定义用于eic的覆盖栈访问的abi以及定义对来自去特权代码的系统/外部调用的处置。abi是一种调用规范，在该调用规范之下，调用方和被调用方要遵守特定行为责任。如本文所使用的，abi指定在调用中段寄存器或被调用方的能力如何被加载，以及在调用中段寄存器或调用方的能力如何被卸载。类似地，abi指定在被调用方完成而调用方需要从被调用方完成的点恢复的情况下如何反向地执行相应的加载/卸载。在实施例中，abi声明：对存储器的所有引用都作为eic来传递并以特定二进制格式被置于被调用方的栈上(例如，由mac/边界/指针的位字段组成)以使其与包含用于指针的单个位字段的常规指针相区分。在所例示的示例中，特权模式路径5204绕过eic信息5202的能力约束。

图52b示出了控制子页许可的方法5206。在实施例中，方法5206被实现为被存储在诸如ram、rom、prom、固件、闪存等非瞬态机器可读或计算机可读存储介质中的一组逻辑指令中的一个或多个模块，被实现在诸如举例来说pla、fpga、cpld等可配置逻辑中，被实现在使用诸如举例来说asic、cmos或ttl技术等电路技术的固定功能硬件逻辑中，或被实现为以上任何组合。

所例示的处理框5208检测功能的调用，其中在框5210作出关于该功能是否以去特权模式被调用的确定。如已经提及的，去特权模式可以提供一种框架，该框架使功能在沙箱环境中运行同时共享由多个存储器段构成的地址空间。响应于该功能正以去特权模式被调用，所例示的框5212对该功能访问共享存储器空间的尝试实施一个或多个能力约束。在一个示例中，框5212包括定义用于eic的覆盖栈访问的abi，以及定义对来自去特权代码的系统/外部调用的处置，以及实施用于存储器访问的eic语义。因此，所例示的方法解决了对每服务器每秒包含极其大量调用的faas系统中的有限数目的可用段描述符以及较低数目的段寄存器的担忧。

代码段描述符和代码段寄存器可以被扩展以存储能力认证密钥，在加载每一描述符时能力认证密钥会被自动加载到eic认证密钥寄存器中。替换地，代码段选择符可以被用作eic认证方案和/或算法的输入(例如，与mac生成过程的其他输入串接或作为密码微调)。

替换地，能力认证密钥或用于eic认证方案和/或算法的其他输入可以从其他段寄存器(例如，数据段/ds、额外段/es、通用段(fs、gs)、或栈段/ss)中汲取。

附加注解与示例

示例5201包括至少一种计算机可读存储介质，其包括一组可执行程序指令，该指令在由计算系统执行时致使该计算系统：检测功能的调用，确定该功能以去特权模式被调用，以及响应于该功能以去特权模式被调用对该功能访问共享存储器空间的尝试实施一个或多个能力约束。

术语“耦合的”在本文中可被用于表示所讨论的组件之间的任何类型的直接或间接关系，且可应用于电气的、机械的、流体的、光学的、电磁的、机电的或其他连接。另外，术语“第一”、“第二”等在本文中可仅用于便于讨论，并且不带有特定时间的或按时间顺序的意义，除非另有陈述。

如在本申请和权利要求书中所使用的，由术语“中的一个或多个”联接的项列表可意指所列项的任何组合。例如，短语“a、b或c中的一个或多个”可意指a；b；c；a和b；a和c；b和c；或a、b和c。

本领域技术人员从前面的描述将领会，实施例的广泛技术能以各种形式来实现。因此，尽管已结合其特定示例描述了实施例，但实施例的真实范围不应当限于此，因为在研究附图、说明书和所附权利要求书之后，其他修改对于本领域技术人员将变得显而易见。

如将理解的，如在本文中所使用的计算机和/或计算设备可包括各种电路系统，包括但不限于cpu、gpu、fpga、asic等。

权利要求书(按照条约第19条的修改)

1.至少一种计算机可读存储介质，包括用于向多个用户提供增强的功能即服务(faas)的一组可执行计算机编程指令，所述一组可执行计算机编程指令在由计算系统执行时致使所述计算系统：

响应于从所述多个用户接收到的一个或多个事件，在所述计算系统中的一个或多个架构子系统上执行多个功能，所述一个或多个架构子系统表示用于所述多个功能的执行环境以及与所述多个功能相关联的多个容器的抽象；

由所述计算系统中的一个或多个软件和编排子系统分配所述计算系统的多个计算资源以促成所述多个功能的执行；

分析与所述多个功能相关联的多个参数以及与所述多个计算资源相关联的多个参数；

将所述多个功能以及对与所述多个功能和所述多个计算资源相关联的多个参数的分析存储在所述计算系统中的一个或多个联网和存储子系统中，用于存储所述多个功能和对多个参数的分析的位置被选择成用于增强所述多个功能和对应的多个计算资源之间的局部性并且用于降低功能执行等待时间；以及

通过所述计算系统中的一个或多个安全子系统来保证所述多个功能的执行的安全。

2.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

监视所述多个功能中的一个或多个功能的执行；

将所述计算系统的一个或多个计算资源划分成一个或多个共享资源，所述多个功能中的每一功能具有对所述一个或多个共享资源的访问权；

提供分配用于执行所述多个功能的一个或多个计算资源的调度，所述调度至少基于正被所述计算系统执行的功能的基于历史的资源调度来生成；

将所述一个或多个功能的数据重定向到所选计算设备以供执行；

根据与所述一个或多个功能相关联的服务水平参数来选择所述多个功能中的一个或多个功能；

将所选一个或多个功能组合成经组合功能以供执行。

3.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

接收用于调用所述多个功能中的第二功能的触发代理，所述第二功能在所述多个功能中的、当前正被执行的功能之后被执行；

向所述触发代理提供反馈以指示对第二功能调用准备就绪；

响应于所述多个功能中的功能是多租户加速功能，发起所述功能的一个或多个版本；

在与所述多个功能的执行相关联的执行动作之间提供同步，所述执行动作被分布在与所述多个功能相关联的多个计算设备和/或容器之间；以及

响应于准则被满足来触发所述第二功能调用。

4.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

标识所述多个功能中的两个或更多个功能之间的共享信息；

分析被调用以供执行的功能是否要求所述共享信息以供执行；以及

基于所述分析将所述功能路由到执行环境。

5.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

在功能的初始执行期间分析所述功能；

将根据对所述功能的分析而生成的使用数据作为元数据文件存储以用于对所述功能的后续调用，对所述功能的每一调用生成用于所述功能的至少一个元数据文件；

基于一个或多个因素来回收所述功能，所述一个或多个因素中的每一者指示所述功能的执行状态，所述执行状态指示是否要回收所述功能；以及

将安全策略应用于所述功能，所述安全策略与所述功能的执行环境相关联，所述功能的一个或多个功能集用相同的安全密钥被编码。

6.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

标识所述多个功能中的功能的一个或多个计算资源需要；

在所述功能被指派到的容器中预留一个或多个所标识的计算资源，每一所标识的计算资源具有资源目录标识；

应用加速器以评估用于所述功能的特定工作负载的成本函数；

在预留的计算资源与所述功能的调用之间构造数据传递和通信链路以减少数据传递或降低通信等待时间；以及

监视与所述功能的执行相关联的一个或多个服务质量(qos)测量，至少一个qos测量由向量定义。

7.如权利要求6所述的至少一种计算机可读存储介质，进一步包括可执行计算机编程指令，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

在执行所述功能的运行时检测一个或多个异常，所述异常在执行所述功能的运行时中使用动态概况分析能力来检测；

将所述一个或多个异常的检测的结果报告给至少一个性能分析工具；以及

基于所述功能的动态概况分析能力来维护功能的简档映射。

8.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

将资源特性与被执行的功能进行关联以生成所述被执行的功能在所述功能的每一执行阶段的需求指纹，所述需求指纹与所述功能的参数以及调用所述功能的至少一个租户相关联，并且所述需求指纹是基于经训练的序列分析机器学习模型的应用而生成的；

生成关于不同资源在所述功能的多个执行阶段的使用的报告；以及

基于所生成的报告将资源分配给所述功能以用于执行所述功能。

9.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

检测第一调用实例对返回字段集的功能的第一调用；

标识所述字段集的第一子集，所述第一子集与所述第一调用实例相关联；以及

基于所述第一子集执行对第一响应对象的第一重布局，所述第一响应对象的重布局对所述第一响应对象进行重排序或重配置。

10.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

确定用于所述多个功能中的功能的有效载荷；以及

在编译时放置按照包含足以作出调用的信息的格式将所述有效载荷构建到调用栈上的代码，其中所述功能能够经由所述有效载荷被统一地调用为本地实例、远程实例或硬件。

11.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

确定与所述多个功能中的第一功能相关联的能力信息相对于第一认证格式是否有效，其中所述能力信息和所述第一认证格式对应于所述第一功能；

在所述能力信息相对于所述第一认证格式有效的情况下将所述能力信息存储到队列；以及

根据对应于所述多个功能中的第二功能的第二认证格式将所述能力信息传递到所述第二功能，其中所述第一功能和所述第二功能是便携式功能，便携式功能具有便携式身份并且能够由负载均衡器在整个计算系统中动态地移动，并且其中所述能力信息包括分层编码的内联能力和用户级中断。

12.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

将密钥标识符映射到第一密钥，其中所述第一密钥与第一功能以及用所述第一密钥加密的第一存储器区域相关联；

检测从所述第一功能到第二功能的上下文切换；以及

响应于所述上下文切换将所述密钥标识符映射到第二密钥，

其中所述第二密钥与所述第二功能以及用所述第二密钥加密的第二存储器区域相关联，

其中所述第一存储器区域和所述第二存储器区域共享线性地址范围，

其中所述第一密钥是用于第一目标域的密钥而所述第二密钥是用于第二目标域的密钥，并且其中所述第一目标域或所述第二目标域中的一者或多者是信任域的子域。

13.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

检测相对于所述多个功能中的功能集的数目不足的保护密钥标识符；

响应于所述数目不足的保护密钥标识符，指令主机计算设备更新页表条目，其中所述功能集限于托管运行时功能；以及

实施所述功能集的原子执行。

14.如权利要求1所述的至少一种计算机可读存储介质，其特征在于，所述可执行计算机编程指令在由所述计算系统执行时致使所述计算系统：

确定软件线程是否正在硬件逻辑线程上运行；

在所述软件线程正在所述硬件逻辑线程上运行时，将标签交换进入寄存器；以及

为所述标签设置高速缓存容量和存储器带宽中的至少一者。

15.一种半导体装置，包括：

一个或多个衬底；以及

逻辑，所述逻辑耦合至所述一个或多个衬底，其中所述逻辑至少部分地被实现在可配置逻辑或固定功能硬件逻辑中的一者或多者中，耦合至所述一个或多个衬底的所述逻辑用于：

响应于从多个用户接收到的一个或多个事件，在计算系统中的一个或多个架构子系统上执行多个功能，所述一个或多个架构子系统表示用于所述多个功能的执行环境以及与所述多个功能相关联的多个容器的抽象；

由所述计算系统中的一个或多个软件和编排子系统分配所述计算系统的多个计算资源以促成所述多个功能的执行；

分析与所述多个功能相关联的多个参数以及与所述多个计算资源相关联的多个参数；

将所述多个功能以及对与所述多个功能和计算资源相关联的多个参数的分析存储在所述计算系统中的一个或多个联网和存储子系统中，用于存储所述多个功能和对多个参数的分析的位置被选择成用于增强所述多个功能和对应的多个计算资源之间的局部性并且用于降低功能执行等待时间；以及

通过所述计算系统中的一个或多个安全子系统来保证所述多个功能的执行的安全。

16.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

监视所述多个功能中的一个或多个功能的执行；

将所述计算系统的一个或多个计算资源划分成一个或多个共享资源，所述多个功能中的每一功能具有对所述一个或多个共享资源的访问权；

提供分配用于执行所述多个功能的一个或多个计算资源的调度，所述调度至少基于正被所述计算系统执行的功能的基于历史的资源调度来生成；

将所述一个或多个功能的数据重定向到所选计算设备以供执行；

根据与所述一个或多个功能相关联的服务水平参数来选择所述多个功能中的一个或多个功能；

将所选一个或多个功能组合成经组合功能以供执行。

17.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

接收用于调用所述多个功能中的第二功能的触发代理，所述第二功能在所述多个功能中的、当前正被执行的功能之后被执行；

向所述触发代理提供反馈以指示对第二功能调用准备就绪；

响应于所述多个功能中的功能是多租户加速功能，发起所述功能的一个或多个版本；

在与所述多个功能的执行相关联的执行动作之间提供同步，所述执行动作被分布在与所述多个功能相关联的多个计算设备和/或容器之间；以及

响应于准则被满足来触发所述第二功能调用。

18.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

标识所述多个功能中的两个或更多个功能之间的共享信息；

分析被调用以供执行的功能是否要求所述共享信息以供执行；以及

基于所述分析将所述功能路由到执行环境。

19.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

在功能的初始执行期间分析所述功能；

将根据对所述功能的分析而生成的使用数据作为元数据文件存储以用于对所述功能的后续调用，对所述功能的每一调用生成用于所述功能的至少一个元数据文件；

基于一个或多个因素来回收所述功能，所述一个或多个因素中的每一者指示所述功能的执行状态，所述执行状态指示是否要回收所述功能；以及

将安全策略应用于所述功能，所述安全策略与所述功能的执行环境相关联，所述功能的一个或多个功能集用相同的安全密钥来编码。

20.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

标识所述多个功能中的功能的一个或多个计算资源需要；

在所述功能被指派到的容器中预留一个或多个所标识的计算资源，每一所标识的计算资源具有资源目录标识；

应用加速器以评估用于所述功能的特定工作负载的成本函数；

在预留的计算资源与所述功能的调用之间构造数据传递和通信链路以减少数据传递或降低通信等待时间；以及

监视与所述功能的执行相关联的一个或多个服务质量(qos)测量，至少一个qos测量由向量定义。

21.如权利要求20所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

在执行所述功能的运行时检测一个或多个异常，所述异常在执行所述功能的运行时中使用动态概况分析能力来检测；

将所述一个或多个异常的检测的结果报告给至少一个性能分析工具；以及

基于所述功能的动态概况分析能力来维护功能的简档映射。

22.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

将资源特性与被执行的功能进行关联以生成所述被执行的功能在所述功能的每一执行阶段的需求指纹，所述需求指纹与所述功能的参数以及调用所述功能的至少一个租户相关联，并且所述需求指纹是基于经训练的序列分析机器学习模型的应用而生成的；

生成关于不同资源在所述功能的多个执行阶段的使用的报告；以及

基于所生成的报告将资源分配给所述功能以用于执行所述功能。

23.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

检测第一调用实例对返回字段集的功能的第一调用；

标识所述字段集的第一子集，所述第一子集与所述第一调用实例相关联；以及

基于所述第一子集执行对第一响应对象的第一重布局，所述第一响应对象的重布局对所述第一响应对象进行重排序或重配置。

24.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

确定用于所述多个功能中的功能的有效载荷；以及

在编译时放置按照包含足以作出调用的信息的格式将所述有效载荷构建到调用栈上的代码，其中所述功能能够经由所述有效载荷被统一地调用为本地实例、远程实例或硬件。

25.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

确定与所述多个功能中的第一功能相关联的能力信息相对于第一认证格式是否有效，其中所述能力信息和所述第一认证格式对应于所述第一功能；

在所述能力信息相对于所述第一认证格式有效的情况下将所述能力信息存储到队列；以及

根据对应于所述多个功能中的第二功能的第二认证格式将所述能力信息传递到所述第二功能，其中所述第一功能和所述第二功能是便携式功能，便携式功能具有便携式身份并且能够由负载均衡器在整个计算系统中动态地移动，并且其中所述能力信息包括分层编码的内联能力和用户级中断。

26.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

将密钥标识符映射到第一密钥，其中所述第一密钥与第一功能以及用所述第一密钥加密的第一存储器区域相关联；

检测从所述第一功能到第二功能的上下文切换；以及

响应于所述上下文切换将所述密钥标识符映射到第二密钥，

其中所述第二密钥与所述第二功能以及用所述第二密钥加密的第二存储器区域相关联，

其中所述第一存储器区域和所述第二存储器区域共享线性地址范围，

其中所述第一密钥是用于第一目标域的密钥而所述第二密钥是用于第二目标域的密钥，并且其中所述第一目标域或所述第二目标域中的一者或多者是信任域的子域。

27.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

检测相对于所述多个功能中的功能集的数目不足的保护密钥标识符；

响应于所述数目不足的保护密钥标识符，指令主机计算设备更新页表条目，其中所述功能集限于托管运行时功能；以及

实施所述功能集的原子执行。

28.如权利要求15所述的半导体装置，其特征在于，耦合至所述一个或多个衬底的所述逻辑用于：

确定软件线程是否正在硬件逻辑线程上运行；

在所述软件线程正在所述硬件逻辑线程上运行时，将标签交换进入寄存器；以及

为所述标签设置高速缓存容量和存储器带宽中的至少一者。

29.一种系统，包括：

存储器；以及

耦合至所述存储器的处理器，所述处理器包括用于执行以下操作的逻辑：

响应于从多个用户接收到的一个或多个事件，在计算系统中的一个或多个架构子系统上执行多个功能，所述一个或多个架构子系统表示用于所述多个功能的执行环境以及与所述多个功能相关联的多个容器的抽象；

由所述计算系统中的一个或多个软件和编排子系统分配所述计算系统的多个计算资源以促成所述多个功能的执行；

分析与所述多个功能相关联的多个参数以及与所述多个计算资源相关联的多个参数；

将所述多个功能以及对与所述多个功能和所述多个计算资源相关联的多个参数的分析存储在所述计算系统中的一个或多个联网和存储子系统中，用于存储所述多个功能和对多个参数的分析的位置被选择成用于增强所述多个功能和对应的多个计算资源之间的局部性并且用于降低功能执行等待时间；以及

通过所述计算系统中的一个或多个安全子系统来保证所述多个功能的执行的安全。

30.一种方法，包括：

响应于从多个用户接收到的一个或多个事件，在计算系统中的一个或多个架构子系统上执行多个功能，所述一个或多个架构子系统表示用于所述多个功能的执行环境以及与所述多个功能相关联的多个容器的抽象；

由所述计算系统中的一个或多个软件和编排子系统分配所述计算系统的多个计算资源以促成所述多个功能的执行；

分析与所述多个功能相关联的多个参数以及与所述多个计算资源相关联的多个参数；

将所述多个功能以及对与所述多个功能和计算资源相关联的多个参数的分析存储在所述计算系统中的一个或多个联网和存储子系统中，用于存储所述多个功能和对多个参数的分析的位置被选择成用于增强所述多个功能和对应的多个计算资源之间的局部性并且用于降低功能执行等待时间；以及

通过所述计算系统中的一个或多个安全子系统来保证所述多个功能的执行的安全。