Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [patch] fix SMT scheduler latency bug | Date | Thu, 23 Jun 2005 09:03:53 +1000 |
| |
On Thu, 23 Jun 2005 02:04, Ingo Molnar wrote: > * Con Kolivas <kernel@kolivas.org> wrote: > > > [...] > > > if (((smt_curr->time_slice * (100 - > > > sd->per_cpu_gain) / 100) > task_timeslice(p))) > > > ret = 1; > > > > > > note that in contrast to the comment above, we dont actually do the > > > check based on static priority, we do the check based on timeslices. > > > But timeslices go up and down, and even highprio tasks can randomly > > > have very low timeslices (just before their next refill) and can thus > > > be judged as 'lowprio' by the above piece of code. > > > > I don't see it like that. task_timeslice(p) will always return the > > same value based purely on static priority and smt_curr->time_slice > > cannot ever be larger than task_timeslice(p) unless there is a > > significant enough 'nice' difference. [...] > > task_timeslice(p) is indeed constant over time, but smt_curr->time_slice > is not. So this condition opens up the possibility of a lower prio > thread accumulating a larger ->time_slice and thus reversing the > priority equation.
I'm not clear on how the value of ->time_slice can ever grow to larger than task_timeslice(p). It starts at task_timeslice(p) and decrements till it gets to 0 when it refills again.
I only recall three times that the value of p->time_slice is increased: New timeslice where it is refilled with task_timeslice(p) At fork() where if it has one tick left it is increased back to one tick Reaping a child where it collects its child's time_slice up to a maximum of task_timeslice(p).
I must be missing something but I can't see how p->time_slice can ever be larger than task_timeslice(p).
Please correct me :|
Cheers, Con [unhandled content-type:application/pgp-signature] | |