基于Linux-5.10，有补充Linux-5.15的说明
一、优先级相关结构体和成员
1. struct binder_priority
struct binder_priority { //binder_internal.h unsigned int sched_policy; int prio; };
此结构用于对服务的binder线程的调度策略和优先级进行描述。
sched_policy: 此成员表示调度策略，binder驱动只支持 SCHED_NORMAL、SCHED_BATCH、SCHED_FIFO、SCHED_RR 这几类调度策略的继承。
prio: 表示内核优先级，对于 SCHED_NORMAL 是[100..139]，对于 FIFO/RT 是[0..99]。
在内核空间，此结构的prio取值[0, 139], sched_policy取内核优先级对应的策略，见 binder_proc_transaction() 中的 node_prio 变量。
2. struct binder_node
struct binder_node { //binder_internal.h ... struct { ... u8 sched_policy:2; u8 inherit_rt:1; u8 min_priority; }; };
sched_policy: 节点的binder服务线程最小优先级对应的调度策略，初始化后就不再变化了。
inherit_rt: 是否允许本服务的binder线程从caller那里继承RT调度策略。若不允许但caller又是RT线程，那么就将响应的binder线程设置为CFS 120优先级。
min_priority: 节点的binder服务线程最小调度优先级，初始化后就不再变化了。相当于将向binder线程传递的最低优先级钳位到这个值上，见 binder_transaction_priority().
是在创建binder服务时，根据用户传入的 flat_binder_object::flags 成员进行初始化，具体初始化位置在 binder_init_node_ilocked() 中:
static struct binder_node *binder_init_node_ilocked(struct binder_proc *proc, struct binder_node *new_node, struct flat_binder_object *fp) { struct binder_node *node = new_node; __u32 flags = fp ? fp->flags : 0; //优先级相关配置来自flags成员 s8 priority; ... priority = flags & FLAT_BINDER_FLAG_PRIORITY_MASK; node->sched_policy = (flags & FLAT_BINDER_FLAG_SCHED_POLICY_MASK) >> FLAT_BINDER_FLAG_SCHED_POLICY_SHIFT; /*用户配置下来的是用户优先级，需要转换 */ node->min_priority = to_kernel_prio(node->sched_policy, priority); node->inherit_rt = !!(flags & FLAT_BINDER_FLAG_INHERIT_RT); ... }
调用路径:
binder_thread_write //1.注册binder服务时 binder_transaction binder_translate_binder binder_translate_binder binder_ioctl_set_ctx_mgr //2.将自己设置为servicemanage时 binder_new_node binder_init_node_ilocked
假设服务还没注册，就还不存在于 proc->nodes 红黑树上，此时就是对参数 new_node 进行初始化。可以看到优先级和调度策略都是来自 flat_binder_object::flags 成员，根据用户传下来的调度策略和优先级转化成一个内核优先级，保存在 node->min_priority 成员中。
开机启动过程中:
(1) 对于 min_priority 成员，主要是主线程是 system_server 的线程(超大量)创建 binder_node 时传参 min_priority=120，其它如主线程是 com.android.phone、MmsServiceMain、idmap2d、com.qti.ltebc 等也有传
min_priority=120 的情况，其它绝大多数线程传的 min_priority=139。而且只有120和139这两个配置值。
(2) 对于 sched_policy 成员，全部传的都是0(SCHED_NORMAL)。
(3) 对于 inherit_rt 成员，极个别的传的是1，比如主线程是 perf-hal-servic、m.android.phone 等的线程，其它的都是0。
在正常使用手机的过程中，也会不停的创建binder node。
3. struct binder_proc
struct binder_proc { //binder_internal.h ... struct binder_priority default_priority; };
default_priority: 在调用 binder_open() 时进行赋值，若调用者是CFS或RT线程，直接赋值为调用者的优先级，若是不支持的调度策略则赋值为prio=120的CFS优先级。
static int binder_open(struct inode *nodp, struct file *filp) { ... if (binder_supported_policy(current->policy)) { proc->default_priority.sched_policy = current->policy; proc->default_priority.prio = current->normal_prio; } else { proc->default_priority.sched_policy = SCHED_NORMAL; proc->default_priority.prio = NICE_TO_PRIO(0); } ... }
开机启动过程中，一般都是主线程执行 binder_open() 的动作，但是也有个别特殊情况，比如辅线程 PowerManagerSer(主线程system_server)、surfaceflinger 也执行了打开binder设备节点的操作。
开机启动过程中:
(1) 对于 default_priority.sched_policy 全部赋值为0(SCHED_NORMAL)
(2) 对于 default_priority.prio 绝大多数都是120，只有极个别是116,104,97等。
在正常使用机器的过程中，也会有不断打开binder节点的动作。
4. struct binder_transaction
struct binder_transaction { ... struct binder_priority priority; struct binder_priority saved_priority; bool set_priority_called; ... }
priority: 对于同步传输赋值为发起传输的caller的优先级(虽然没有区分reply，但是reply没有使用这个成员)。对异步传输赋值为目标进程的 target_proc->default_priority。若binder不支持
caller的调度策略，也赋值为target_proc->default_priority，见 binder_transaction()。
saved_priority: 在将要改变server的binder线程的优先级时，将其保存在这个成员中，以便之后进行恢复。见发起传输时的 binder_transaction_priority() 和 binder_transaction() 的reply部分。
set_priority_called: 在 binder_transaction_priority() 中唯一判断和设置。在client端发起传输和service的binder线程读取传输时都有设置binder优先级动作，这个成员标记针对当前 transaction t 的优先级传递是否已经设置了。若选到了thread，则在发起传输的caller进行传输进行时进行设置，若是没有选到thread，则在binder线程读取时进行设置。
//发起设置： binder_proc_transaction struct binder_priority node_prio; node_prio.prio = node->min_priority; node_prio.sched_policy = node->sched_policy; /* 若是选到了thread，挂在thread->todo链表上是才会设置，挂在proc->todo和node->async_todo上时都不会设置 */ if (thread) { binder_transaction_priority(thread->task, t, node_prio, node->inherit_rt); binder_enqueue_thread_work_ilocked(thread, &t->work); } //读取设置： binder_thread_read /* 此判断表示是服务端读取 */ if (t->buffer->target_node) { struct binder_priority node_prio; node_prio.sched_policy = target_node->sched_policy; node_prio.prio = target_node->min_priority; binder_transaction_priority(current, t, node_prio, target_node->inherit_rt); }
5. binder_pri_desc/binder_pri_ptr_cookie
struct binder_pri_desc { //uapi/binder.h __s32 priority; __u32 desc; }; struct binder_pri_ptr_cookie { //uapi/binder.h __s32 priority; binder_uintptr_t ptr; binder_uintptr_t cookie; };
对应 binder 优先级相关 ioctl 设置的参数，目前还不支持设置。
6. flat_binder_object::flags
enum flat_binder_object_shifts { FLAT_BINDER_FLAG_SCHED_POLICY_SHIFT = 9, }; enum flat_binder_object_flags { ... FLAT_BINDER_FLAG_PRIORITY_MASK = 0xff, FLAT_BINDER_FLAG_SCHED_POLICY_MASK = 3U << FLAT_BINDER_FLAG_SCHED_POLICY_SHIFT, FLAT_BINDER_FLAG_INHERIT_RT = 0x800, ... };
此结构用来定义户空间设置下来的 flat_binder_object::flags 成员各个bit位的含义，在注册服务创建 binder_node 时在 binder_init_node_ilocked() 函数中进行解析。
FLAT_BINDER_FLAG_PRIORITY_MASK：最小调度优先级的位掩码。这些位可用于设置进入该node的事务应运行的最低调度优先级。这些位中的有效值取决于@FLAT_BINDER_FLAG_SCHED_POLICY_MASK 中编码的调度策略。
SCHED_NORMAL/SCHED_BATCH，有效范围在 [-20..19] 之间，对于 SCHED_FIFO/SCHED_RR，该值可以在 [1..99] 之间运行。
FLAT_BINDER_FLAG_SCHED_POLICY_MASK: 调度策略的位掩码。这两位可用于设置该Node上的事务应运行的最小调度策略。这些匹配 UAPI 调度程序策略值，例如：0=SCHED_NORMAL, 1=SCHED_FIFO, 2=SCHED_RR, 3=SCHED_BATCH.
FLAT_BINDER_FLAG_INHERIT_RT: 节点是否继承RT策略。仅当设置时，对该Node的调用将继承调用者的实时调度策略(用于同步传输)。
二、优先级相关函数
1. 底层函数
static bool is_rt_policy(int policy) { return policy == SCHED_FIFO || policy == SCHED_RR; } static bool is_fair_policy(int policy) { return policy == SCHED_NORMAL || policy == SCHED_BATCH; } /* binder只支持RT和CFS */ static bool binder_supported_policy(int policy) { return is_fair_policy(policy) || is_rt_policy(policy); } /* 内核优先级转用户优先级 */ static int to_userspace_prio(int policy, int kernel_priority) { if (is_fair_policy(policy)) return PRIO_TO_NICE(kernel_priority); else return MAX_USER_RT_PRIO - 1 - kernel_priority; } /* 用户优先级转内核优先级 */ static int to_kernel_prio(int policy, int user_priority) { if (is_fair_policy(policy)) return NICE_TO_PRIO(user_priority); else return MAX_USER_RT_PRIO - 1 - user_priority; } /* 被 binder_transaction_priority 唯一调用 */ static void binder_set_priority(struct task_struct *task, struct binder_priority desired) { /* set的时候是需要verify的 */ binder_do_set_priority(task, desired, /* verify = */ true); } static void binder_restore_priority(struct task_struct *task, struct binder_priority desired) { /* restore的时候不需要verify的 */ binder_do_set_priority(task, desired, /* verify = */ false); }
2. binder_transaction_priority() 函数实现
static void binder_transaction_priority(struct task_struct *task, struct binder_transaction *t, struct binder_priority node_prio, bool inherit_rt) { struct binder_priority desired_prio = t->priority; bool skip = false; /* 对此成员唯一判断和赋值路径 */ if (t->set_priority_called) return; /* 保存到 saved_priority 成员中 */ t->set_priority_called = true; t->saved_priority.sched_policy = task->policy; t->saved_priority.prio = task->normal_prio; trace_android_vh_binder_priority_skip(task, &skip); if (skip) return; /* 若目标是RT线程，但是又不允许继承RT，就改为prio=120的CFS优先级 */ if (!inherit_rt && is_rt_policy(desired_prio.sched_policy)) { desired_prio.prio = NICE_TO_PRIO(0); desired_prio.sched_policy = SCHED_NORMAL; } /* binder最低优先级限制还比发起传输的线程优先级高，那就取优先级高的 */ if (node_prio.prio < t->priority.prio || (node_prio.prio == t->priority.prio && node_prio.sched_policy == SCHED_FIFO)) { /* * 翻译：如果Node上的最低优先级较高(数值较小)，请使用Node的优先级。 * 如果优先级相同，但Node服务的使用的是 SCHED_FIFO(大部分设置的就是它)，则首选 * SCHED_FIFO，因为与 SCHED_RR 不同，它可以无限运行。 */ desired_prio = node_prio; } /* 实际设置优先级的函数 */ binder_set_priority(task, desired_prio); trace_android_vh_binder_set_priority(t, task); }
binder_set_priority() 只是调用 binder_do_set_priority(task, desired, /* verify = */ true)，后者实现如下：
/* * 若传参 verify=true，会校验task是否有 CAP_SYS_NICE 权限，若没有，只能设置到其 * rlimt运行的最高优先级。若传false则没有这个校验。 */ static void binder_do_set_priority(struct task_struct *task, struct binder_priority desired, bool verify) { int priority; /* user-space prio value */ bool has_cap_nice; unsigned int policy = desired.sched_policy; /* task的优先级已经和要设置的优先级是一样的了，直接退出 */ if (task->policy == policy && task->normal_prio == desired.prio) return; has_cap_nice = has_capability_noaudit(task, CAP_SYS_NICE); /* 这里又转换为用户优先级 */ priority = to_userspace_prio(policy, desired.prio); /* 需要校验，要设为RT，又没有 CAP_SYS_NICE 权限(若有这个权限就可以忽略rlimit限制) */ if (verify && is_rt_policy(policy) && !has_cap_nice) { /* * 为0表示task不允许被设置为RT线程，那就设置为prio=100 * 的CFS线程，否则设置为最大允许的RT优先级。 * 注: 上面已经转换为用户Rt优先级了，数值越大优先级越高。 */ long max_rtprio = task_rlimit(task, RLIMIT_RTPRIO); if (max_rtprio == 0) { policy = SCHED_NORMAL; priority = MIN_NICE; } else if (priority > max_rtprio) { priority = max_rtprio; } } /* 需要校验，要设为CFS，又没有 CAP_SYS_NICE 权限 */ if (verify && is_fair_policy(policy) && !has_cap_nice) { /* 只能设置到task所支持的最大CFS优先级 */ long min_nice = rlimit_to_nice(task_rlimit(task, RLIMIT_NICE)); if (min_nice > MAX_NICE) { binder_user_error("%d RLIMIT_NICE not set\n", task->pid); return; } else if (priority < min_nice) { priority = min_nice; } } /* 实际设置的和外部传参要求设置的不一致，给个debug打印 */ if (policy != desired.sched_policy || to_kernel_prio(policy, priority) != desired.prio) binder_debug(BINDER_DEBUG_PRIORITY_CAP, "%d: priority %d not allowed, using %d instead\n", task->pid, desired.prio, to_kernel_prio(policy, priority)); /* * 这个会打印出task设置前的优先级，要设置的优先级和调用者希望设置的优先级 * HwBinder:2957_2-4054 [001] ...2 101180.500974: binder_set_priority: proc=1490 thread=1490 old=120 => new=105 desired=105 //binder线程优先级升高 * Loc_hal_worker-1426 [000] ...2 101334.089782: binder_set_priority: proc=2957 thread=7091 old=105 => new=120 desired=120 //binder线程优先级降低 */ trace_binder_set_priority(task->tgid, task->pid, task->normal_prio, to_kernel_prio(policy, priority), desired.prio); /* Set the actual priority */ /* * 设置调度策略和RT优先级，对于正在运行的任务，从trace上看这个设置不会打断其运行。 * 若是RT设置为CFS，这个函数调用后设置为CFS 120优先级。 * * 对于policy=0，prio=0的设置，下面因判断不是fair policy，就只设置成了CFS 120优先级。 */ if (task->policy != policy || is_rt_policy(policy)) { struct sched_param params; params.sched_priority = is_rt_policy(policy) ? priority : 0; sched_setscheduler_nocheck(task, policy | SCHED_RESET_ON_FORK, ¶ms); } /* 设置CFS优先级 */ if (is_fair_policy(policy)) set_user_nice(task, priority); }
binder_transaction_priority()函数作用: 将task设置为 t->priority 指定的优先级。但是受参数和服务对自己binder优先级配置的影响，设置逻辑如下：
(1) 若服务配置不允许自己的binder线程继承RT优先级，而 t->priority 又是RT线程，就将响应的binder线程设置为优先级为120的CFS线程。
(2) 若服务允许自己binder线程运行的最低优先级比 t->priority 还高，就将响应的binder线程设置为服务允许的最低优先级。
(3) 底层函数传参 verify=true,还会校验 CAP_SYS_NICE 权限，若没有这个权限，只能设置 rlimit 允许的最高优先级。
3. 从函数调用路径中可以看出，这组优先级传递函数中，对外的函数分别是 binder_transaction_priority() 和 binder_restore_priority()，则看这两个函数的调用路径：
(1) binder_transaction_priority 调用路径
binder_ioctl case BINDER_WRITE_READ: binder_ioctl_write_read binder_thread_write case BC_TRANSACTION/BC_REPLY: binder_transaction(proc, thread, &tr, cmd == BC_REPLY, 0); //好像没用这里 case BC_TRANSACTION_SG/BC_REPLY_SG: //4.X内核上用这个 binder_transaction(proc, thread, &tr.transaction_data, cmd == BC_REPLY_SG, tr.buffers_size); binder_proc_transaction //发起同步传输 binder_transaction_priority //《调用路径1》 binder_proc_transaction //发起的异步传输 binder_transaction_priority //《调用路径2》 binder_ioctl case BINDER_WRITE_READ: binder_ioctl_write_read(filp, cmd, arg, thread); binder_thread_read binder_transaction_priority //同步传输服务端读 《调用路径3》
(2) binder_restore_priority 调用路径：
binder_ioctl case BINDER_WRITE_READ: binder_ioctl_write_read(filp, cmd, arg, thread); binder_thread_read if (wait_for_proc_work) binder_restore_priority(current, proc->default_priority); //将要休眠《调用路径4》 binder_ioctl case BINDER_WRITE_READ: binder_ioctl_write_read binder_thread_write case BC_TRANSACTION_SG/BC_REPLY_SG: binder_transaction if (reply) binder_restore_priority(current, in_reply_to->saved_priority); //对同步传输的reply《调用路径5》 if (in_reply_to) binder_restore_priority(current, in_reply_to->saved_priority); //这个是传输报错后的处理路径
可见，binder优先级的传递都发生在 ioctl write/read 时刻。要搞清楚优先级传递，只需要搞清 binder_transaction_priority() 和 binder_restore_priority() 在各种传输场景下各参数和 t->priority 含义即可。
三、优先级传递逻辑
1. client sync transaction
static void binder_transaction(struct binder_proc *proc, struct binder_thread *thread, struct binder_transaction_data *tr, int reply, binder_size_t extra_buffers_size) { struct binder_transaction *t, *in_reply_to = NULL;; if (reply) { /* client端发起请求时创建的binder_transaction结构 */ in_reply_to = thread->transaction_stack; } ... /* 同步传输(但是也没区分reply，单reply不用此成员),赋值的是调用线程的优先级 */ if (!(t->flags & TF_ONE_WAY) && binder_supported_policy(current->policy)) { /* Inherit supported policies for synchronous transactions */ t->priority.sched_policy = current->policy; t->priority.prio = current->normal_prio; } else { /* Otherwise, fall back to the default priority 赋值为目标主线程优先级 */ t->priority = target_proc->default_priority; } t->work.type = BINDER_WORK_TRANSACTION; if (reply) { //reply /* 对同步传输的reply, 将服务的binder线程设置为之前的优先级 */ binder_restore_priority(current, in_reply_to->saved_priority); //《调用路径5》 } else if (!(t->flags & TF_ONE_WAY)) { //sync transaction t->need_reply = 1; t->from_parent = thread->transaction_stack; thread->transaction_stack = t; binder_inner_proc_unlock(proc); /* 此函数中会传递优先级 */ binder_proc_transaction(t, target_proc, target_thread); } else { //async transaction binder_proc_transaction(t, target_proc, NULL); } ... } static int binder_proc_transaction(struct binder_transaction *t, struct binder_proc *proc, struct binder_thread *thread) { thread = binder_select_thread_ilocked(proc); if (thread) { /* 不区分同步传输还是异步传输 */ binder_transaction_priority(thread->task, t, node_prio, node->inherit_rt); //《调用路径1》《调用路径2》 /* 将work放在binder线程的thread->todo链表上 */ binder_enqueue_thread_work_ilocked(thread, &t->work); } else if (!pending_async) { /* 若是挂在其它链表上则不会设置优先级 */ binder_enqueue_work_ilocked(&t->work, &proc->todo); } else { binder_enqueue_work_ilocked(&t->work, &node->async_todo); } ... if (!pending_async) /* 然后唤醒服务的binder线程 */ binder_wakeup_thread_ilocked(proc, thread, !oneway /* sync */); ... }
此过程对应上面《调用路径1》，binder_proc_transaction 调用传参 (thread->task, t, node_prio, node->inherit_rt)，参数依次为：
thread->task：响应请求的服务的binder线程，
t: 发起传输的 client 构造的，其 t->priority 成员同步传输来自调用线程，异步传输来自 target_proc->default_priority，见 binder_transaction()。
node_prio: 服务 node 对自己的 binder 线程指定的最小优先级限制，分别取自 node->min_priority/node->sched_policy。
node->inherit_rt: 服务是否允许自己的 binder 线程继承RT优先级, 创建服务时由用户的 flat_binder_object::flags 配置，若不允许，当RT线程call过来时就将服务的binder线程设置为prio=120的CFS优先级。
解释起来就是在client发起同步传输过程中尝试将响应我们请求的 binder 线程设置为发起binder传输的线程的优先级。但是设置下去的最终优先级是受 binder_node 对地板和 CAP_SYS_NICE 对天花板的限制的。
2. client async transaction
此过程对应上面《调用路径2》，和上面同步传输过程几乎一致，不同点在于对于异步传输中 t->priority 来自 target_proc->default_priority，也就是服务端执行 binder_open() 线程的优先级。
解释起来就是在client发起异步传输过程中尝试将响应我们请求的 binder 线程设置为服务端执行 binder_open() 线程的优先级(一般是服务主线程)。
3. server read sync transaction
static int binder_thread_read(struct binder_proc *proc, struct binder_thread *thread, binder_uintptr_t binder_buffer, size_t size, binder_size_t *consumed, int non_block) { int wait_for_proc_work; /* * 判断一个thread能否用来处理proc的work，对于同步传输，thread->transaction_stack 不为NULL， * 对于同步传输和异步传输 thread->todo 链表上都有work, 就返回false。 * 只有对于异步的又没有选到thread线程将work挂在proc->todo链表上时的请求才可能返回true，但是 * 概率应该较低，虽然这里设置成了proc->default_priority(异步传输t->priority保存的也是service * 执行binder_open()时的优先级)，下面会再次根据t来进行设置的，不会出现优先级出错。 * * 但是线程在处理完同步/异步请求之后，要进行阻塞休眠时的下一次读，这里会返回true，因此要 * 进入休眠的binder线程会设置为 proc->default_priority。 */ wait_for_proc_work = binder_available_for_proc_work_ilocked(thread); if (wait_for_proc_work) { /* 应该是 */ binder_restore_priority(current, proc->default_priority); //《调用路径4》 } /* 平时无work要处理时在这里休眠 */ binder_wait_for_work(thread, wait_for_proc_work); while (1) { struct binder_work *w = NULL; struct binder_transaction *t = NULL; /* 能处理proc的work才会从proc->todo链表上取任务下来 */ if (!binder_worklist_empty_ilocked(&thread->todo)) list = &thread->todo; else if (!binder_worklist_empty_ilocked(&proc->todo) && wait_for_proc_work) list = &proc->todo; switch (w->type) { case BINDER_WORK_TRANSACTION: { binder_inner_proc_unlock(proc); t = container_of(w, struct binder_transaction, work); } break; ... } ... /* server端读取执行位置 */ if (t->buffer->target_node) { /* 目标服务node, 对于service的binder线程就是自己服务的node */ struct binder_node *target_node = t->buffer->target_node; struct binder_priority node_prio; trd->target.ptr = target_node->ptr; trd->cookie = target_node->cookie; node_prio.sched_policy = target_node->sched_policy; node_prio.prio = target_node->min_priority; /* 对于work对于的每一个transaction都执行，此时current就是服务的binder线程 */ binder_transaction_priority(current, t, node_prio, target_node->inherit_rt); //《调用路径3》 cmd = BR_TRANSACTION; } else { /* client端读取执行位置 */ trd->target.ptr = 0; trd->cookie = 0; cmd = BR_REPLY; } } ... }
对应于《调用路径3》，service端读取时，对于每一个work对应的transaction都会执行 binder_transaction_priority(), 由于通过 t->set_priority_called 做了针对一个t防止重复设置的机制，
若是从thread->todo链表上取下来的work不会执行，若是从proc->todo链表上取下来的才会执行。
4. server read async transaction
也对应于《调用路径3》，对于异步传输，虽然《调用路径4》也有可能对binder线程进行设置，但是随后又会在下面《调用路径3》中设置回t->priority。
对于《调用路径4》的传参可以看出，service执行open(/dev/binder)节点后再设置其优先级是不合适的，因为其 proc->default_priority 成员只在open binder节点时赋值一次，但是surfaceflinger偏偏在
open节点之后设置了自己的优先级。
4. server reply
对应于《调用路径5》, service端在对client端进行reply时会将自己binder线程的优先级设置回之前的状态。
5. client read
client读取路径中不涉及优先级传递。
四、优先级相关Trace和HOOK
1. 相关DEBUG Trace
(1) 打印binder线程当前的优先级和期望设置的优先级和最终要被设置的优先级
binder_do_set_priority trace_binder_set_priority(task->tgid, task->pid, task->normal_prio, to_kernel_prio(policy, priority), desired.prio); HwBinder:1643_2-2089 [003] ..... 6910.598526: binder_set_priority: proc=1643 thread=2089 old=120 => new=97 desired=97 HwBinder:1643_2-2089 [003] ..... 6910.615109: binder_set_priority: proc=1643 thread=2089 old=97 => new=0 desired=0
2. 相关DEBUG Log
(1) 实际设置值和外部传参不同时给个打印
binder_do_set_priority binder_debug(BINDER_DEBUG_PRIORITY_CAP, "%d: priority %d not allowed, using %d instead\n", task->pid, desired.prio, to_kernel_prio(policy, priority)); # echo 8192 > /sys/module/binder/parameters/debug_mask //使对此mask(1<<13)的打印生效
补充：
Linux-5.15内核中改动：
binder_do_set_priority binder_debug(BINDER_DEBUG_PRIORITY_CAP, "%d: priority %d not allowed, using %d instead\n", task->pid, desired->prio, to_kernel_prio(policy, priority)); binder_debug(BINDER_DEBUG_PRIORITY_CAP, "%d: %s: aborting priority restore\n", thread->pid, __func__); binder_transaction_priority binder_debug(BINDER_DEBUG_PRIORITY_CAP, "%d: saved pending priority %d\n", current->pid, thread->prio_next.prio); # dmesg -c | grep binder [ 6448.719215] binder: 17920: saved pending priority 120 [ 6764.256906] binder: 1792: priority 98 not allowed, using 100 instead ...
3. 相关HOOK
binder_transaction_priority trace_android_vh_binder_priority_skip(task, &skip); //用户可以决定是否传递优先级 trace_android_vh_binder_set_priority(t, task); //传递完后也给个HOOK binder_transaction trace_android_vh_binder_restore_priority(in_reply_to, current); //只在reply时有一个 trace_android_vh_binder_restore_priority(in_reply_to, current); //传输失败时 binder_thread_read trace_android_vh_binder_restore_priority(NULL, current); //处理proc的work路径中
五、总结
1. 用户空间对服务node优先级的配置是通过 flat_binder_object::flags 成员设置下来的，见 binder_init_node_ilocked()。
2. binder优先级传递其实就只是对service的binder线程进行的设置。简要总结起来就是在client发起同步binder请求时，尝试将响应请求的binder线程设置为发起线程的优先级，但是对优先级有个限制，不能低于binder node指定的最低优先级，也不能高于rlimit限制的优先级(若无 CAP_SYS_NICE 权限)，在reply时对binder线程的优先级进行恢复; 当client发送异步请求时会进行同样的尝试，将响应请求的binder线程设置为service主线打开binder节点时的优先级(proc->default_priority)后进行响应。
3. 当binder线程没有事情做要休眠等待work时，也会设置为 proc->default_priority, 然后休眠等待.
4. 启动服务时在rc脚本中使用”capabilities SYS_NICE”给服务赋予 CAP_SYS_NICE 权限。
5. 优先级的设置是 per-binder_transaction t 的，对于每一个t都会进行一次优先级传递。
原文地址：http://www.cnblogs.com/hellokitty2/p/16852917.html
