The task isn't running actually. One of its parents up in the heirarchy hasbeen throttled and been already dequeued. Now this task sits on its immediateparent's runqueue which isn't throttled but not really running also sincethe hierarchy is throttled. In this situation, load balancer can try to pullthis task. When that happens, load balancer tries to dequeue it and thischeck will ensure that we don't attempt to dequeue a group entity in ourhierarchy which has already been dequeued.

When a cfs_rq is throttled, its representative se (and all its parentse's) get dequeued and the task is marked for resched. But the task entity isstill on its throttled parent's cfs_rq (=> task->se.on_rq = 1). Next duringput_prev_task_fair(), we enqueue the task back on its throttled parent'scfs_rq at which time we end up calling update_curr() on throttled cfs_rq.This check would help us bail out from that situation.