On Thu, 23 Jun 2005 02:04, Ingo Molnar wrote: > * Con Kolivas <[email protected]> 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:
pgpLWB6DMGeAi.pgp
Description: PGP signature
- Follow-Ups:
- Re: [patch] fix SMT scheduler latency bug
- From: Ingo Molnar <[email protected]>
- Re: [patch] fix SMT scheduler latency bug
- References:
- [patch] fix SMT scheduler latency bug
- From: Ingo Molnar <[email protected]>
- Re: [patch] fix SMT scheduler latency bug
- From: Con Kolivas <[email protected]>
- Re: [patch] fix SMT scheduler latency bug
- From: Ingo Molnar <[email protected]>
- [patch] fix SMT scheduler latency bug
- Prev by Date: Re: Script to help users to report a BUG
- Next by Date: Re: Updated git HOWTO for kernel hackers
- Previous by thread: Re: [patch] fix SMT scheduler latency bug
- Next by thread: Re: [patch] fix SMT scheduler latency bug
- Index(es):
 |