se->cfs_rq->tg与task_of(se)->sched_task_group的区别：定义差异及优势分析

Alright, let's break this down clearly—this is a common point of confusion when digging into Linux CFS scheduler internals. Let's start with core definitions, then dive into their differences and unique strengths.

1. Core Definition Differences #

First, context matters: se is a struct sched_entity, which represents a schedulable entity in CFS. Critically, this can be either a regular process (embedded in struct task_struct) or a task group (embedded in struct task_group). That's the first key distinction most folks miss.

se->cfs_rq->tg #

This points to the task group that owns the CFS runqueue (cfs_rq) where the schedulable entity (se) is currently enqueued:

• For a regular task's se: If the task lives in a sub-task-group's runqueue, this will be that sub-task group. If it's in the root runqueue (no task group), it points to the root task group.
• For a task group's own se (yes, task groups are schedulable entities too): This points to the parent task group whose runqueue contains the child task group's se.

task_of(se)->sched_task_group #

This relies on task_of(se)—a macro that uses container_of to fetch the struct task_struct embedding the se. The sched_task_group field in task_struct points to the static, assigned task group of the process:

• This value only changes if you explicitly move the process to another task group (via cgroup interfaces or sched_setattr).
• Critical caveat: This only works if se belongs to a regular process. If se is part of a task group, task_of(se) returns garbage (since the se is embedded in struct task_group, not task_struct), leading to invalid memory access.

2. Unique Advantages of Each #

Now let's cover when to use which, based on their strengths:

Advantages of se->cfs_rq->tg #

• Works for all schedulable entities: Whether you're dealing with a regular process or a task group's se, this is safe and valid. This is non-negotiable for code that traverses the full scheduler hierarchy (like stats collection or hierarchy-aware scheduling logic).
• Reflects current scheduling context: It tells you exactly which runqueue's task group the entity is part of right now—useful for edge cases where an entity might be transiently migrated between runqueues.
• Hierarchy-aware: For task group entities, it directly gives you the parent task group, making it easy to walk the scheduler hierarchy from child to parent.

Advantages of task_of(se)->sched_task_group #

• Gets the true owning group: This tells you the task's static, assigned group—regardless of transient scheduling state. If you need to check which cgroup a task belongs to (since task groups tie directly to cgroups), this is the right pointer.
• Fast and direct: It's a single pointer dereference from the task struct, faster than traversing se->cfs_rq->tg (two dereferences). If you know you're working with a regular process's se, this is the efficient choice.
• Stable across events: Even if the task is descheduled, migrated, or waiting in a queue, this value stays consistent (unless the task is explicitly moved to another group).

3. Quick Example to Drive It Home #

Suppose we have a hierarchy: root tg → child tg → process P:

• For P's se:
  • se->cfs_rq->tg = child tg (P's se lives in the child tg's runqueue)
  • task_of(se)->sched_task_group = child tg (matches, since P is assigned to the child tg)
• For the child tg's own se (enqueued in the root tg's runqueue):
  • se->cfs_rq->tg = root tg (correct, as this se lives in the root's runqueue)
  • task_of(se)->sched_task_group = invalid (this se belongs to a task group, not a process—don't use this here!)

内容的提问来源于stack exchange，提问作者wuyihao