Re: [PATCH v3] sched/stats: Fix run_delay over-count for migrated sched_delayed tasks

[Kayra Cizmeci <kayracizmeci@gmail.com>]

Hi Peter,

> Will we not have a similar problem with proxy exec? 
> That is, would t->is_blocked be more appropriate?

Yeah.

Only place that sets is_blocked to 1 is try_to_block_task(), which gets only called from __schedule.

Also, we give should_block param. !task_is_blocked(), so 
if there are a pointer we return false on try_to_block_task(), so on task_is_blocked() true case,
and that means proxy tasks stay in rq. With blocked 1. So yeah, we have a similar problem on proxy exec. 

To the second one tho, I think using task_is_blocked() would be better. Since, the current code 
looks to that for whether or not queue the proxy. 


And, on some places is_blocked is cleared after enqueu. My brain stopped working 2 hours ago,
this proxy execution stuff combined with delayed fries my brain. So I might be wrong, please correct me if so.

as far as I can tell reading tho. I'm sick of using tho. tho. :-)

Thanks,
Kayra