1. 论文基本信息 (Bibliographic Information)

• 标题 (Title): ALPS: An Adaptive Learning, Priority OS Scheduler for Serverless Functions (ALPS：一个用于无服务器函数的自适应学习、优先级操作系统调度器)
• 作者 (Authors): Yuqi Fu (University of Virginia), Ruizhe Shi (George Mason University), Haoliang Wang (Adobe Research), Songqing Chen (George Mason University), Yue Cheng (University of Virginia)
• 发表期刊/会议 (Journal/Conference): 2024 USENIX Annual Technical Conference (ATC '24)。USENIX ATC 是计算机系统领域的顶级学术会议之一，享有很高的声誉和影响力。
• 发表年份 (Publication Year): 2024
• 摘要 (Abstract): 无服务器 (FaaS) 工作负载具有独特的模式：函数是短暂、高并发、突发性的，执行时间从几毫秒到几秒不等。这给内核调度带来了新挑战。Linux 默认的 CFS 调度器对工作负载无感知，通过比例共享优化长期公平性，但忽略了短函数的短期 CPU 需求，严重影响其性能。理论上最优的 SRPT (最短剩余处理时间优先) 调度器虽然能极大优化短函数的周转时间，但可能导致长函数“饿死”。本文提出了 ALPS (自适应学习、优先级调度器)，一个新颖的应用感知内核调度器。ALPS 基于两个核心思想：1) 近似 SRPT 对短函数有益但可能损害长函数；2) CFS 提供了实现用户定义优先级调度的基础架构。为此，ALPS 设计了创新的、解耦的前后端架构。前端在用户空间，通过对近期历史工作负载进行 SRPT 仿真，自适应地学习调度策略。后端利用挂载到 CFS 的 eBPF 函数，在内核中执行前端发送的策略。这种设计在保留操作系统调度器优良特性的同时，为调度决策引入了工作负载智能。在两个生产 FaaS 工作负载（华为和 Azure）上的评估表明，与 CFS 相比，ALPS 使平均函数执行时长降低了 57.2%。
• 原文链接 (Source Link): /files/papers/68f4c9c3e3046a80be581939/paper.pdf (已正式发表于 USENIX ATC '24 会议论文集)

2. 整体概括 (Executive Summary)

• 研究背景与动机 (Background & Motivation - Why):

  • 核心问题： 传统的通用操作系统调度器，如 Linux 的 CFS，无法高效处理现代无服务器计算（FaaS）的工作负载。
  • 问题重要性与挑战： FaaS 函数具有短生命周期、高并发和突发性的特点。CFS 的设计目标是“公平”，它将 CPU 时间按比例分配给所有任务，这导致短函数即使只需要再运行几毫秒，也可能被强制中断（上下文切换），然后排队等待下一次调度，从而极大地延长了它们的总执行时间（周转时间）。对于 FaaS 平台而言，这直接损害了服务质量 (QoS) 和成本效益。虽然理论上最优的 SRPT 策略（优先处理剩余时间最短的任务）能解决这个问题，但它有两个致命缺陷：1) 无法预知未来的任务剩余时间；2) 会导致长任务长时间得不到执行（即“饿死”）。
  • 切入点/创新思路： 论文的创新思路是不替换、只增强。它不试图从零开始构建一个全新的内核调度器，而是巧妙地利用 CFS 的现有机制，并通过 eBPF 技术在内核中“注入”对工作负载的感知能力。其核心是在用户空间学习，在内核空间执行的解耦思想，通过模拟理想的 SRPT 行为来指导现实中的 CFS 调度，从而在 SRPT 的高效和 CFS 的公平之间取得平衡。

• 核心贡献/主要发现 (Main Contribution/Findings - What):

  • 提出了 ALPS，一个新颖的应用感知内核调度器。 其最大的创新是解耦的前后端架构：
    1. 用户空间前端 (Frontend): 负责“学习”。它收集近期的函数执行历史，运行 SRPT 仿真，从中学习出两套策略：任务排序策略 (哪个函数更优先) 和 时间片策略 (一个函数一次应该运行多久)。
    2. 内核空间后端 (Backend): 负责“执行”。它利用 eBPF 技术，在不修改内核源码的情况下，将前端学习到的策略应用到 CFS 的关键决策点上，动态调整函数的调度顺序和时间片。
  • 统一了近似 SRPT 和比例共享调度。 ALPS 能够为短函数提供类似 SRPT 的高优先级和长时片，让它们尽快完成；同时，对于长函数或预测不准的情况，则回退到 CFS 的默认公平调度机制，防止“饿死”。
  • 实现了显著的性能提升。 实验证明，在真实的生产工作负载下，ALPS 相比 CFS 平均函数执行时间减少了 57.2%，相比此前的先进工作 SFS 减少了 20.6%，并且有效缓解了 SRPT 的长尾延迟问题。

3. 预备知识与相关工作 (Prerequisite Knowledge & Related Work)

• 基础概念 (Foundational Concepts):

  • FaaS (Function-as-a-Service - 函数即服务): 一种无服务器计算模型，允许开发者只编写和部署独立的函数代码，而无需管理底层服务器。云平台会根据请求自动扩展和运行这些函数。FaaS 函数通常是无状态的、事件驱动的、短暂的，执行环境（如容器）在执行完毕后很快被销毁。
  • CFS (Completely Fair Scheduler - 完全公平调度器): Linux 内核默认的 CPU 调度器。其核心目标不是让每个任务轮流运行相同的时间，而是按比例分享 CPU。它通过一个名为 vruntime (虚拟运行时间) 的概念来实现。每个任务都有一个 vruntime，它会随着任务实际运行而增加。CFS 总是选择 vruntime 最小的任务来运行。高优先级的任务 vruntime 增长得慢，因此能获得更多的 CPU 时间。对于大量短任务，CFS 的“公平”会导致它们频繁地被抢占，执行效率低下。
  • SRPT (Shortest Remaining Processing Time - 最短剩余处理时间优先): 一种抢占式的调度算法。在任何时刻，调度器总是选择剩余执行时间最短的任务来运行。如果有新任务到达且其剩余时间比当前正在运行的任务还短，调度器会立即抢占当前任务，切换到新任务。该算法被证明在最小化平均周转时间方面是理论最优的。但它需要预知未来（任务的剩余时间），且存在饿死（starvation）长任务的风险。
  • eBPF (extended Berkeley Packet Filter - 扩展伯克利包过滤器): 一项革命性的 Linux 内核技术，允许在不修改内核源码或加载内核模块的情况下，在内核中运行一段沙箱化的、安全的程序。eBPF 程序可以被“挂载”到内核的各种钩子点 (hook points)上，当内核执行到这些点时，就会触发 eBPF 程序的执行。它还提供了 eBPF maps，一种高效的键值存储，用于在用户空间和内核空间之间共享数据。ALPS 正是利用 eBPF 在 CFS 的调度决策点插入自定义逻辑，并使用 eBPF maps 传递学习到的策略。

• 前人工作 (Previous Works):

  • SFS (Serverless Function Scheduler): 这是一个专门为无服务器函数设计的用户空间调度器。它采用两级调度：一个 FIFO (先进先出) 队列处理它认为是“短”的函数，如果函数在预设的时间片内没运行完，就会被降级到第二个 CFS 队列中。SFS 的主要局限在于：1) 需要修改 FaaS 平台应用；2) 在用户空间控制内核调度，控制粒度粗、效率低，且需要不断轮询内核状态；3) 调度开销较大。
  • 其他用户定义调度器 (e.g., ghOSt, Syrup): 这些工作也探索了用户自定义调度，但通常需要将调度逻辑嵌入到应用程序中，对应用有侵入性。ALPS 的设计则对 FaaS 平台是透明的，移植成本低。
  • 近似 SRPT 的方法 (e.g., ADS): 一些研究尝试通过启发式规则（如网络请求大小）来预测任务时长，从而近似 SRPT。但对于复杂的 FaaS 函数，执行时间很难通过简单的外部特征来预测。

• 差异化分析 (Differentiation): ALPS 与上述工作的核心区别在于：

  1. 架构创新: 采用用户空间学习 + 内核空间执行的解耦架构，兼顾了灵活性和高性能。
  2. 非侵入式增强: 利用 eBPF 增强而非替换 CFS，继承了 CFS 的稳定性和公平性保障，同时降低了实现复杂度和风险。
  3. 学习方法: 不直接预测函数的绝对执行时间，而是通过模拟 SRPT 行为来学习函数的相对优先级 (基于平均等待时间) 和典型时间片，这种方法对预测误差的容忍度更高。
  4. 透明性: 对 FaaS 应用完全透明，只需要 FaaS 平台在启动函数容器时调用一个特定的系统调用即可，移植性好。

4. 方法论 (Methodology - Core Technology & Implementation Details)

ALPS 的核心设计体现在其解耦的前后端架构中。

该图像是图4，展示了ALPS调度器架构的示意图，包含用户态的前端模块（滑动窗口、SRPT仿真、策略训练与更新）和内核态的后端模块（基于eBPF的映射与调度钩子），实现函数调度的时片划分与任务顺序预测。

上图 Figure 4 直观地展示了 ALPS 的整体架构和工作流程。

• 方法原理 (Methodology Principles): ALPS 的核心思想是“从理想指导现实”。它假设 SRPT 是一个理想的“老师”，虽然无法在现实中完美实现，但可以通过分析“老师”在历史数据上的行为模式（即 SRPT 仿真），学到一套实用的、近似的调度规则，然后用这套规则去指导现实中 CFS 的行为。为了实现这一点，它将复杂的 SRPT 调度问题分解为两个更简单的子问题：任务排序和时间片分配。

• 方法步骤与流程 (Steps & Procedures): 结合 Figure 4，ALPS 的工作流程如下：

  1. 收集历史数据 (Sliding window): 前端在一个滑动窗口内（例如过去 5 秒）收集所有已完成函数的执行记录，包括函数唯一标识符 (function_UID)、到达时间、结束时间以及理想 CPU 时间。
  2. SRPT 仿真 (SRPT simulation): 前端利用收集到的历史数据，运行一次离线的 SRPT 调度仿真。这次仿真会产出每个函数在理想 SRPT 调度下的详细行为统计，如每次被调度时的等待时间、每次运行的时间片长度等。
  3. 策略训练 (Policy training):
     • 3.1 基础策略学习: 基于仿真结果，为每个 function_UID 学习两个基础策略：
       • 任务排序策略: 计算每个函数在仿真中的平均等待时间，等待时间越短，意味着在 SRPT 中优先级越高。然后将所有函数按平均等待时间排序，分配一个全局排名 (rank)。
       • 时间片策略: 收集每个函数在仿真中获得的所有时间片长度，形成一个向量 $\vec{ts}_i$，然后通过一个轻量级预测模型（如求平均值）计算出一个基础时间片 $ts_i$。
     • 3.2 策略微调 (Fine-tuning): 为了应对现实世界的不确定性（如预测误差、负载突变），ALPS 对基础时间片进行两步微调。
  4. 策略更新 (Policy updating): 前端将最终学习到的排名和时间片策略写入 eBPF maps 中，供内核后端使用。
  5. 性能剖析 (Profiled CPU time): 内核中的 eBPF 钩子在函数执行时，会剖析其消耗的 CPU 时间，并将这个值（作为理想 CPU 时间的近似）通过 eBPF maps 反馈给前端，用于下一轮的 SRPT 仿真。
  6. 内核调度决策 (Time slice & task order prediction): 当 CFS 需要做调度决策时，ALPS 的 eBPF 钩子被触发。它会根据当前任务的 func_id 从 eBPF maps 中查询学习到的排名和时间片，并据此影响 CFS 的任务排序和抢占决策。

• 数学公式与关键细节 (Mathematical Formulas & Key Details):

  • 时间片策略学习: 基础时间片 $ts_i$ 的计算如下： $$ts_i = \mathrm{train\_ts}(\vec{ts}_i)$$ 其中，$\mathrm{train\_ts}()$ 可以是 average、linear regression、random forest 或 EWMA 等模型。$\vec{ts}_i$ 是函数 $i$ 在 SRPT 仿真中得到的时间片向量。

  • 时间片微调 - 处理不确定性: 为了解决预测不准的问题（尤其是对执行时间多变的函数），ALPS 使用以下公式调整时间片： $$ts_i^u = \max(\alpha \times ts_i - \beta \times \mathrm{stdev}(\vec{ts}_i), 0)$$

    • 符号解释:
      • $ts_i^u$: 经过不确定性调整后的时间片。
      • $\alpha$: 奖励因子 (reward factor)。$\alpha > 1$ 会延长基础时间片，目的是为了让那些差一点就能运行完的函数一次性完成，避免不必要的上下文切换。
      • $\beta$: 惩罚因子 (penalty factor)。它乘以时间片向量的标准差 $\mathrm{stdev}(\vec{ts}_i)$。对于历史上时间片变化剧烈的函数（标准差大），这个惩罚项会削减其分配到的时间片，使其行为更接近 CFS，避免因过长的错误预测而阻塞其他函数。
      • $\max(\cdot, 0)$: 确保时间片不为负数。

  • 时间片微调 - 处理系统过载: 当系统 CPU 负载过高时，激进地延长某些函数的时间片可能会加剧系统雪崩。因此，ALPS 引入了一个全局惩罚因子 $p$： $$p = \begin{cases} 1 & \text{if } l < \Theta \\ \frac{100 + \Theta - l}{100 \times \gamma} & \text{if } l \geq \Theta \end{cases}$$

    • 符号解释:
      • $l$: 实时 CPU 利用率。
      • $\Theta$: CPU 利用率阈值。当负载低于此阈值时，不进行惩罚。
      • $\gamma$: 反应因子 (reaction factor)。$\gamma$ 越小，惩罚力度越大（$p$ 值越小）。 最终的时间片 $ts_i^s$ 由 $ts_i^s = \min(p \times ts_i^u, ts_i^u)$ 得到，确保调整后的时间片不会超过未过载时的值。

  • 内核后端实现 (eBPF Hooks):

    • 时间片控制: ALPS 在 CFS 的核心调度函数 __schedule() 中挂载了一个 eBPF 程序。该程序检查当前任务的已运行时间是否超过了从 eBPF map 中查到的 $ts_i^s$。如果未超过，程序返回 1，指示 CFS “不要抢占，让它继续跑”，从而延长了时间片。否则返回 0，执行 CFS 的默认抢占逻辑。
    • 任务排序控制: ALPS 在 CFS 用于比较两个任务优先级的函数 entity_before() 中挂载了另一个 eBPF 程序。该程序从 eBPF map 查询两个待比较任务的 rank 值。如果 rank 值不同，则直接根据 rank 值决定谁更优先。如果 rank 相同或查询不到，则回退到 CFS 原本基于 vruntime 的比较逻辑。

5. 实验设置 (Experimental Setup)

• 数据集 (Datasets):

  • 实验使用了两个公开的生产 FaaS 工作负载跟踪数据：华为云函数 (Huawei Cloud Functions) 和 Azure Functions。

  • 特点:

    • Huawei trace: 数据高度倾斜，绝大多数 (约 93%) 都是执行时间小于 200ms 的短函数。
    • Azure trace: 函数执行时长的分布则相对均衡。

  • 数据处理: 作者从两个数据集中分别采样了 15,000 个调用请求，并将这些请求映射到他们自己实现的 6 种基准函数应用（如斐波那契、广度优先搜索等）的 50 个不同参数配置的部署上。这种方法既保留了生产负载的到达模式，又能在受控环境中复现不同执行时长的函数。为了模拟真实场景，他们还为人为制造了执行时长的方差（最多 25%）。

  • 以下是论文中 Table 1 的转录，展示了两个数据集中函数按执行时长的分组分布情况：

    Group	Duration Range	Huawei	Azure
    1	0-50 ms	69.8%	42.9%
    2	50-200 ms	23.2%	17.2%
    3	200-400 ms	6%	16.7%
    4	≥ 400 ms	1%	23.2%

• 评估指标 (Evaluation Metrics):

  • 函数执行时长 (Function Execution Duration):
    1. 概念定义: 也称为周转时间 (Turnaround Time)。它衡量一个函数从被请求调用开始，到最终执行完成返回结果所花费的总时间。这个指标直接反映了用户感受到的端到端延迟，是评估 FaaS 平台性能的核心指标。值越低越好。
    2. 数学公式: $$\text{Duration} = T_{\text{termination}} - T_{\text{arrival}}$$
    3. 符号解释:
       • $T_{\text{termination}}$: 函数执行完成的时间点。
       • $T_{\text{arrival}}$: 函数被请求调用的时间点。
  • 上下文切换次数 (Number of Context Switches):
    1. 概念定义: 指在一个函数的整个生命周期中，CPU 从该函数切换到另一个任务的次数。频繁的上下文切换本身会带来开销，并且意味着函数在执行过程中被多次中断，其等待被重新调度的时间会显著增加总执行时长。这个指标是分析调度器效率的重要辅助指标。值越低越好。
    2. 数学公式: 这是一个直接计数值，没有标准公式。
    3. 符号解释: N/A

• 对比基线 (Baselines):

  • Linux 默认调度器:
    • CFS (SCHED_NORMAL): 论文最主要的比较对象，代表了当前云厂商的普遍实践。
    • FIFO (SCHED_FIFO): 非抢占式的先进先出调度器。
    • RR (SCHED_RR): 带时间片的轮转调度器。
  • 领域前沿工作: SFS (Serverless Function Scheduler)，一个先进的专为 FaaS 设计的用户空间调度器。
  • 理论最优基准: 离线 SRPT (Offline SRPT)，它假设能预知所有函数的精确执行时间，并以此做出最优调度。它代表了平均执行时长的理论下限。

6. 实验结果与分析 (Results & Analysis)

• 核心结果分析 (Core Results Analysis):

  该图像是包含四个子图的图表，展示了五种调度策略在两个生产FaaS工作负载（华为和Azure）上的函数执行时长和时间片累积分布函数（CDF）表现，分别为(a)华为时长CDF，(b)Azure时长CDF，(c)华为时间片CDF，(d)Azure时间片CDF。

  上图 Figure 1 展示了不同调度器在两个数据集上的宏观性能。

  • 从 (a) 和 (b) 的时长 CDF 图可以看出，CFS、FIFO 和 RR 的性能远劣于理论最优的 SRPT。SFS 居中，优于 CFS 但仍有较大差距。

  • 一个有趣的发现是，在短函数为主的华为工作负载 (a) 中，SRPT 在尾部（>99%）出现了极高的延迟，证实了其可能饿死长任务的理论缺陷。

  • 从 (c) 和 (d) 的时间片 CDF 图可以看出，CFS 和 SFS 分配的时间片非常短且集中，导致了大量的上下文切换。而 SRPT 则能给短任务分配足以一次性跑完的长时片。

    该图像是图表，展示了图8中ALPS相较于CFS函数执行时间、Openlambda整体服务时间（OL）和华为函数整体服务时间（HF）的时间缩减百分比。图中以华为和Azure两个负载为例，箱线图表示时间缩减的分布情况。

  上图 Figure 5 详细对比了 ALPS、CFS 和 SFS 在不同负载和函数分组下的性能。

  • ALPS 全面领先: 在所有负载水平（70% 到 90% CPU 利用率）和所有函数分组（Group 1 到 Group 4）中，ALPS 的执行时长都显著低于 CFS 和 SFS。

  • 负载越高，优势越明显: 随着系统负载增加，CFS 和 SFS 的性能急剧恶化，而 ALPS 的性能则保持相对稳定，显示出其在高压环境下的鲁棒性。

  • 对长函数同样有效: ALPS 不仅优化了短函数（Group 1, 2），对长函数（Group 3, 4）的性能提升甚至更显著。这是因为它通过避免短函数的频繁抢占，为长函数争取了更连续的执行时间。

    该图像是三幅CDF曲线图，展示了不同预测模型和参数对函数执行时长的影响。左图比较了平均值、线性回归、随机森林和EWMA模型预测性能，中间图展示了不同滑动窗口大小对预测的影响，右图展示了参数α变化对结果的影响。

  上图 Figure 7 对比了上下文切换次数。ALPS 极大地减少了上下文切换，其分布情况非常接近理论最优的 SRPT，而远优于 CFS 和 SFS。这直接解释了 ALPS 高性能的来源：让函数尽可能一次性运行完毕，减少无谓的等待和切换开销。

• 消融实验/参数分析 (Ablation Studies / Parameter Analysis):

  该图像是三幅CDF曲线图，展示了不同预测模型和参数对函数执行时长的影响。左图比较了平均值、线性回归、随机森林和EWMA模型预测性能，中间图展示了不同滑动窗口大小对预测的影响，右图展示了参数α变化对结果的影响。

  上图展示了 ALPS 内部不同组件和参数选择的影响。

  • 学习模型选择 (左图): 结果表明，使用简单的 Average (平均值) 或 EWMA (指数加权移动平均) 模型来学习时间片，其性能与复杂的 Linear Regression (线性回归) 或 Random Forest (随机森林) 模型几乎没有差别。这证明了 ALPS 的思想对模型复杂度不敏感，可以使用轻量级模型以降低前端开销。

  • 滑动窗口大小 (中图): 在 5 秒到 30 秒的范围内改变滑动窗口大小，对最终性能影响很小。这说明 ALPS 的学习过程对历史数据的窗口长度不敏感，具有很好的鲁棒性。

  • 微调参数敏感性 (右图及 Figure 13):

    该图像是两个CDF（累积分布函数）图表，分别展示了参数β和γ对函数持续时间分布的影响，其中横轴为持续时间（ms），纵轴为累积分布值（CDF）。

  实验结果表明，ALPS 对微调参数 $\alpha$ (奖励)、$\beta$ (惩罚) 和 $\gamma$ (反应) 也不敏感。在很宽的参数范围内，性能都保持稳定。例如，当 $\alpha$ 从 1 增加到 10 时，性能只有微小变化。这表明 ALPS 的设计非常健壮，在实际部署中不需要进行繁琐的参数调优。

7. 总结与思考 (Conclusion & Personal Thoughts)

• 结论总结 (Conclusion Summary): 该论文成功地论证了现有通用 OS 调度器 CFS 在 FaaS 场景下的低效性，并提出了一个创新、实用且高效的解决方案 ALPS。ALPS 的核心贡献在于其解耦的“学习-执行”架构，它通过在用户空间模拟 SRPT 行为来学习调度策略，并利用 eBPF 在内核空间高效、安全地执行这些策略，从而在不替换 CFS 的前提下，实现了对其行为的智能增强。实验结果强有力地证明，ALPS 能够在真实 FaaS 工作负载下大幅降低函数执行时长，性能超越了现有的通用及专用调度器，同时有效规避了 SRPT 策略的饿死问题。

• 局限性与未来工作 (Limitations & Future Work): 论文作者在第9节（讨论）中坦诚地指出了一个主要的局限性：当前 ALPS 的设计主要关注函数的 UID，而没有显式地考虑函数输入大小变化导致执行时间剧烈波动的情况。 虽然微调策略中的标准差惩罚项 $\beta \times \mathrm{stdev}(\vec{ts}_i)$ 在一定程度上能缓解这个问题，但更精确的模型可以将函数输入（例如 HTTP 请求的大小）作为特征之一。未来的工作可以探索将这类应用层信息融入到 ALPS 的学习模型中，以做出更精准的调度决策。

• 个人启发与批判 (Personal Insights & Critique):

  • 启发:

    1. “增强而非替换”的设计哲学： ALPS 最令人欣赏的一点是它的实用主义。它没有试图推倒重来，而是站在 CFS 这个“巨人”的肩膀上，通过 eBPF 这一“外科手术式”的工具进行增强。这种方法在工程上更具可行性，更容易被工业界接受。
    2. “从理想到现实”的学习范式： 通过模拟一个理论最优但无法实现的模型 (SRPT) 来指导一个现实模型的行为，是一种非常聪明的思路。它绕开了直接预测未来的难题，转而学习一种“行为模式”或“相对优先级”，这大大提升了系统的鲁棒性。
    3. eBPF 的巨大潜力： 这篇论文是展示 eBPF 在操作系统内核可编程性方面巨大潜力的绝佳案例。它证明了 eBPF 不仅可以用于网络和观测性，还能对像 CPU 调度器这样核心的子系统进行深度、安全的定制。

  • 批判性思考与潜在问题:

    1. “理想 CPU 时间”的获取： 论文提到前端仿真需要函数的“理想 CPU 时间”，而后端通过 eBPF 剖析来获取。但在一个高负载的生产环境中，任何函数的执行都或多或少受到干扰，如何精确地获得一个无干扰的“理想”时间是一个挑战。论文对此的说明不够详细，这个环节的准确性可能会影响整个学习系统的效果。
    2. 对工作负载模式的依赖： ALPS 的学习机制假设了工作负载在滑动窗口内具有一定的平稳性和重复性。对于那些模式突变非常剧烈、历史不具备参考价值的场景（例如，大量从未见过的新函数突然涌入），ALPS 的性能可能会退化到接近 CFS（因为查不到策略），其冷启动和适应新模式的速度值得进一步探究。
    3. 实验规模的简化： 实验中将成千上万个唯一的生产函数映射到 50 个部署上，这是一个显著的简化。在真实世界中，函数 UID 的基数可能非常大，这会对 eBPF maps 的大小和前端学习模型的内存/计算开销带来挑战。ALPS 在超大规模函数数量下的可扩展性仍需验证。