On 11/12/2015 02:03 PM, Vikram Mulukutla wrote:
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?
Yep. It looks like the migration paths in core.c were missed and don't have the hooks to update CPU capacity votes.
I've added this to my todo list. Not sure what your tree looks like/what version of the code you've got but you probably want to put the same hooks used to adjust CPU capacity in the load balance path in migration_cpu_stop() as well. In the latest that's update_capacity_of(cpu).