Hi Peter, I have a question about wakeup granularity calculation while checking if the waking fair task can preempt the current running fair task.
static unsigned long wakeup_gran(struct sched_entity *curr, struct sched_entity *se) { unsigned long gran = sysctl_sched_wakeup_granularity; /* * Since its curr running now, convert the gran from real-time * to virtual-time in his units. * * By using 'se' instead of 'curr' we penalize light tasks, so * they get preempted easier. That is, if 'se' < 'curr' then * the resulting gran will be larger, therefore penalizing the * lighter, if otoh 'se' > 'curr' then the resulting gran will * be smaller, again penalizing the lighter task. * * This is especially important for buddies when the leftmost * task is higher priority than the buddy. */ return calc_delta_fair(gran, se); } The above comment says that the wakeup granularity will be larger when 'se' < 'curr'. But we completely ignore the weight of the curr and scale the wakeup granularity solely based on the weight of the waking task i.e se. For example, when curr is nice:0 and se is nice:0, the wakeup granularity is unchanged. However when curr is nice:-15 and se is nice:-15, the granularity becomes 3% of its original value and favour the waking task. The git history around these functions revealed that there was once a sched feature called ASYM_GRAN with which we can control the granularity scaling wrt curr or se. However if we scale granularity wrt curr, then preemption becomes difficult for a higher waking up task. Is there any reason why we don't want to take both curr and se into account? scaled_granularity = granularity * (W(curr)/W(se)) I don't have any particular usecase that actually shows a regression. I spotted this behavior in traces where a lower or default prio task that is riding on the wakeup bonus is preempting a higher prio task which started just running. Setting sched_wakeup_granularity to a value higher than the wakeup bouns may prevent this, but that would make things difficult for a normal prio tasks preempting a lower prio running task. Thanks, Pavan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.