Re: [patch] fix SMT scheduler latency bug

[Con Kolivas]

On Thu, 23 Jun 2005 02:04, Ingo Molnar wrote:
> * Con Kolivas <kernel@xxxxxxxxxxx> 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

Attachment: pgp00000.pgp
Description: PGP signature