On Mon, May 6, 2013 at 8:24 PM, Alex Shi <alex....@intel.com> wrote: > On 05/07/2013 11:06 AM, Paul Turner wrote: >>> > Thanks Paul! >>> > It seems work with this change if new __sched_fork move after the >>> > p->sched_reset_on_fork setting. >>> > >>> > But why we initial avg sum to 1024? new task may goes to sleep, the >>> > initial 1024 give a unreasonable initial value. >>> > >>> > guess let the task accumulate itself avg sum and period is more natural. >> 1024 is a full single unit period representing ~1ms of time. >> >> The reason to store a small initial "observation" here is so that as >> when we reach our next period edge our load converges (presumably >> down) towards its true target more smoothly; as well as providing a >> task additional protection from being considered "small" through >> start-up. >> > > It will give new forked task 1 ms extra running time. That will bring > incorrect info if the new forked goes to sleep a while.
This is intentional. Either: The sleep was representative, we still converge reasonably quickly to zero. The sleep was not representative and we have not under-represented the task. Providing it initial time is entirely about improving numerical stability. > But this info should benefit to some benchmarks like aim7, > pthread_cond_broadcast. So I am convinced. :) > > What's your opinion of this, Peter? > > -- > Thanks > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/