在Linux调度器里，sched_get_priority_max这个POSIX接口经常被用来查询某个调度策略允许的最大优先级。用户空间程序只需传入SCHED_FIFO或者SCHED_RR，就能拿到实时任务的优先级上限。但切换到eBPF内核态编程时，很多人会想当然地寻找一个类似bpf_get_current_task_sched_get_priority_max的helper，结果发现BPF helper列表里根本没有这个函数。为什么会这样？原因在于sched_get_priority_max本质上是用户态对内核调度参数的封装，内核里并不存在同名的系统调用，而是直接通过宏和task_struct字段管理优先级。要理解如何在内核态获取最大优先级，必须先把用户态API和内核实现之间的关系理清楚。
用户态调用sched_get_priority_max时，glibc会触发SYS_sched_get_priority_max系统调用，内核对应的处理函数是sys_sched_get_priority_max。该函数在kernel/sched/core.c中实现，逻辑很简单：先校验policy参数合法性，然后根据policy返回对应的最大优先级。对于SCHED_FIFO和SCHED_RR，返回MAX_USER_RT_PRIO-1，也就是99；对于SCHED_OTHER、SCHED_BATCH、SCHED_IDLE等普通策略，返回0；对于SCHED_DEADLINE则返回0。这里的MAX_USER_RT_PRIO定义为100，所以实时优先级范围是1到99，优先级0保留给非实时任务。内核中还定义了MAX_RT_PRIO作为内核内部实时优先级范围，包含优先级0，但用户空间不可见。这种分层设计意味着在eBPF中不能简单调用一个系统调用，而是需要直接读取task_struct中的policy字段，再结合策略常量推导最大优先级。
从sched_get_priority_max看用户态与内核态的优先级映射
Linux调度优先级分为两个体系：普通任务的nice值（-20到19）和实时任务的rt_priority（1到99）。用户态通过sched_setscheduler设置实时策略时，需要把优先级转换为内核内部的表示。内核task_struct中的prio字段是调度器实际使用的动态优先级，范围0到139，其中0到99对应实时优先级（数值越小优先级越高），100到139对应普通任务的nice映射。而用户态传入的实时优先级1到99会被转换为内核中的prio=MAX_RT_PRIO-1-user_prio，也就是说用户优先级99对应内核prio=0（最高实时优先级）。sched_get_priority_max返回的用户可用最大值99，在内核中对应prio=0。这种倒置关系是新手最容易混淆的地方。
在用户态获取最大优先级可以直接调用sched_get_priority_max，比如下面这段C代码展示了三种典型调度策略的返回值：
#include <stdio.h>
#include <sched.h>
int main() {
printf("SCHED_FIFO max priority: %d\n", sched_get_priority_max(SCHED_FIFO));
printf("SCHED_RR max priority: %d\n", sched_get_priority_max(SCHED_RR));
printf("SCHED_OTHER max priority: %d\n", sched_get_priority_max(SCHED_OTHER));
return 0;
}
输出结果通常是SCHED_FIFO和SCHED_RR都返回99，SCHED_OTHER返回0。需要注意的是，sched_get_priority_max的参数是调度策略，不是进程ID，它只依赖于策略类型。这意味着无论哪个进程调用，只要系统内核配置一致，返回值就是固定的。但在eBPF中，我们往往需要针对当前进程判断它是否达到了实时优先级上限，或者判断一个实时任务是否使用了过高的优先级。此时只靠策略常量还不够，必须结合当前进程的调度策略和实时优先级来分析。
内核中与sched_get_priority_max对应的代码片段大致如下：
SYSCALL_DEFINE1(sched_get_priority_max, int, policy)
{
int ret = -EINVAL;
switch (policy) {
case SCHED_FIFO:
case SCHED_RR:
ret = MAX_USER_RT_PRIO - 1;
break;
case SCHED_DEADLINE:
case SCHED_NORMAL:
case SCHED_BATCH:
case SCHED_IDLE:
ret = 0;
break;
}
return ret;
}
从内核源码可以看出，最大实时优先级被硬编码为MAX_USER_RT_PRIO-1，也就是99。这个宏定义在include/linux/sched/prio.h中，而MAX_USER_RT_PRIO定义为100。所以在eBPF程序里，如果只是想知道实时任务的最大优先级，直接使用数字99是可行的，但这样硬编码会影响可移植性，更好的做法是通过读取当前任务的policy字段，然后自行判断策略类型并映射最大优先级。
eBPF中获取当前任务调度信息和最大优先级的正确姿势
eBPF提供了bpf_get_current_task_btf这个helper，它可以返回当前进程的task_struct指针，并且配合BTF（BPF Type Format）可以安全地读取结构体字段。这是目前主流的获取当前任务信息的方式。通过这个helper拿到task_struct后，可以读取policy、rt_priority等字段。task_struct中的policy字段类型是unsigned int，取值包括SCHED_NORMAL、SCHED_FIFO、SCHED_RR、SCHED_BATCH、SCHED_IDLE、SCHED_DEADLINE等。而rt_priority字段表示实时优先级，取值范围1到99，对于非实时任务该值通常为0。结合这两个字段，我们可以判断当前进程是否是实时进程，以及它的优先级是否已经接近上限。
下面是一段使用libbpf框架编写的BPF程序，它挂载到tracepoint/sched/sched_switch上，当发生进程切换时打印被切换出去的任务的调度策略和实时优先级：
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <linux/sched.h>
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 1 << 20);
} events SEC(".maps");
struct event {
int prev_pid;
unsigned int prev_policy;
unsigned int prev_rt_priority;
};
SEC("tp_btf/sched_switch")
int BPF_PROG(handle_sched_switch, bool preempt, struct task_struct *prev,
struct task_struct *next)
{
struct event *e;
e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);
if (!e)
return 0;
e->prev_pid = prev->pid;
e->prev_policy = prev->policy;
e->prev_rt_priority = prev->rt_priority;
bpf_ringbuf_submit(e, 0);
return 0;
}
char LICENSE[] SEC("license") = "GPL";
这段代码使用了BTF支持的tracepoint直接获取task_struct，比旧式的kprobe读取电流任务更安全。注意helper bpf_get_current_task_btf返回的是当前正在运行的task，而在sched_switch tracepoint中prev和next参数已经是task_struct指针，所以不需要额外调用helper。如果要在其他挂载点获取当前任务，可以这样写：
struct task_struct *task = (struct task_struct *)bpf_get_current_task_btf();
if (!task)
return 0;
unsigned int policy = task->policy;
unsigned int rt_prio = task->rt_priority;
至于最大优先级如何获取，BPF程序无法调用用户态的系统调用或内核的非导出符号，但可以基于policy字段自行判断。例如，当policy是SCHED_FIFO或SCHED_RR时，最大实时优先级为99；当policy是SCHED_OTHER等普通策略时，最大优先级是0。如果想避免硬编码99，可以在BPF程序里使用内核中已经定义的宏MAX_USER_RT_PRIO？BPF程序可以包含内核头文件，但要注意内核头文件中的某些宏可能依赖编译配置，不过MAX_USER_RT_PRIO是固定值100，通常可以直接使用。更稳妥的做法是在用户态查询一次sched_get_priority_max，然后通过BPF map传递给内核程序，这样即使未来内核调整优先级范围也能自动适应。
还有一种思路是利用eBPF的kfunc（内核函数）能力，如果内核版本支持且导出了相关函数，可以直接调用内核的sched_get_priority_max逻辑。不过目前常见内核版本并没有导出这个函数供BPF调用，因此最通用的方法还是读取policy然后映射。下面是一个完整的BPF程序片段，它在每次进程唤醒时判断该进程的实时优先级是否等于最大实时优先级：
SEC("tp_btf/sched_wakeup")
int BPF_PROG(check_rt_prio, struct task_struct *p)
{
if (!p)
return 0;
unsigned int policy = p->policy;
if (policy == SCHED_FIFO || policy == SCHED_RR) {
if (p->rt_priority == 99) {
// 该任务使用了最高实时优先级
bpf_printk("task %d is using max RT priority\n", p->pid);
}
}
return 0;
}
注意这里直接使用了数字99，如果希望更严谨，可以定义常量或者从map读取。另外需要确保BPF程序编译时包含了正确的头文件，SCHED_FIFO等宏定义在linux/sched.h中。
sched_get_priority_max与实时调度策略深挖及常见误区
实时调度策略SCHED_FIFO和SCHED_RR共享同一个优先级范围1到99，但它们的调度行为不同：SCHED_FIFO是先进先出，任务会一直运行直到主动让出CPU或被更高优先级抢占；SCHED_RR则是轮转调度，同优先级任务会分配时间片。很多开发者误以为sched_get_priority_max返回的值可以直接传给sched_setscheduler中的优先级参数，实际上确实可以，因为用户态API的优先级参数范围就是1到99。但必须注意0优先级对于实时策略是非法的，调用sched_setscheduler并传入SCHED_FIFO和优先级0会得到EINVAL错误。也就是说sched_get_priority_min(SCHED_FIFO)返回1，而不是0。而普通策略的sched_get_priority_min和max都返回0，因为它们的优先级用nice值表示，与rt_priority无关。
另一个常见误区是在eBPF程序里把task_struct中的prio字段当成用户态实时优先级。前面提到prio字段范围0到139，对于实时任务，prio=MAX_RT_PRIO-1-rt_priority，也就是说用户态rt_priority=99对应内核prio=0。如果直接读取prio并判断是否达到最大，会得出完全相反的结论。正确的做法是读取rt_priority字段（注意名称是rt_priority，不是rt_prio）。在较老的内核版本中，task_struct可能没有直接暴露rt_priority字段，不过现代5.x及以后的内核都包含该字段。如果使用CO-RE（Compile Once - Run Everywhere）技术，还需要注意字段偏移在不同内核版本间的变化，最好通过BPF_CORE_READ宏来读取。
此外，sched_get_priority_max这个系统调用本身也值得注意：它在Linux上并没有像sched_getparam那样受到实时调度限制，任何用户都可以调用，因为它只返回静态的策略信息。这就意味着即使在非特权容器中，用户也可以查询到SCHED_FIFO的最大优先级是99。但真正要设置实时优先级，则需要CAP_SYS_NICE权限。eBPF程序通常在内核上下文运行，不受用户态权限限制，但也需要遵守BPF验证器的安全检查。因此，通过eBPF获取任务调度信息时，可以直接读取内核结构而无需任何权限申请，这为系统观测工具提供了极大便利。
总结一下，虽然没有名为bpf_get_current_task_sched_get_priority_max的helper，但利用bpf_get_current_task_btf结合task_struct字段，完全可以实现等价的功能。核心逻辑就是：获取当前任务的policy，如果是实时策略则最大优先级为99，如果是普通策略则为0，同时读取rt_priority与最大值比较即可判断任务是否使用了最高实时优先级。理解用户态API到内核实现的映射关系，是写好BPF调度分析程序的关键。
eBPFsched_get_priority_max最大优先级修改时间：2026-09-29 10:53:25