On 11/12/2015 1:37 AM, Juri Lelli wrote:
Hi Vikram,
On 11/11/15, Vikram Mulukutla wrote:
On 11/11/2015 7:42 PM, Vikram Mulukutla wrote:
- There is a single task TaskA on CPU0.
- CPU0 makes a max frequency request as part of enqueue_task_fair
that is ignored because of throttling, but per_cpu(0,capacity) is set to max (in fact it's 1278 after the capacity margin is added).
To be precise, the max request in (2) is made because TaskA was enqueued on CPU0.
- TaskA is forcefully preempted. dequeue_task_fair is invoked but
does not reset capacity since task_sleep=false.
So, why is TaskA preempted? Activation of some other task?
Also, we check for tash_sleep=false because we have triggering points for load_balancing operations (as you might move more than one task at a time). I'm wondering why those points don't cover this case.
So in the particular trace I was looking at it's the sched_exec call that forces the process off of CPU0 to CPU1. So, TaskA started running on CPU0, called do_exec and that led to sched_exec->select_task_rq_fair. That resulted in CPU1 being selected which then caused migration/0 to run on the CPU0 to force TaskA on to CPU1. CPU0 then switched to idle and went to sleep with a max cap request.
I suppose a task setting its own affinity would also potentially result in this situation?
Thanks, Vikram