On Wed, 2008-01-23 at 13:36 +0100, Peter Zijlstra wrote:
> On Wed, 2008-01-23 at 13:18 +0100, Michel Dänzer wrote:
> >
> > 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
> > commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> > Author: Peter Zijlstra <[EMAIL PROTECTED]>
> > Date: Mon Oct 15 17:00:14 2007 +0200
> >
> > sched: another wakeup_granularity fix
> >
> > unit mis-match: wakeup_gran was used against a vruntime
> >
> > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> >
> > :040000 040000 61242d589b0082a417657807ed6329321340f7f3
> > bff39e49275324e15f37d2163157733580b7df1a M kernel
> >
> >
> > Unfortunately, I don't understand how that can cause the misbehaviour
> > described above, and 2.6.24-rc8
> > (667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
> > shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
> >
> >
> > diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> > index da7c061..a7cc22a 100644
> > --- a/kernel/sched_fair.c
> > +++ b/kernel/sched_fair.c
> > @@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct
> > task_struct *p)
> > struct task_struct *curr = rq->curr;
> > struct cfs_rq *cfs_rq = task_cfs_rq(curr);
> > struct sched_entity *se = &curr->se, *pse = &p->se;
> > - unsigned long gran;
> >
> > if (unlikely(rt_prio(p->prio))) {
> > update_rq_clock(rq);
> > @@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct
> > task_struct *p)
> > pse = parent_entity(pse);
> > }
> >
> > - gran = sysctl_sched_wakeup_granularity;
> > - if (unlikely(se->load.weight != NICE_0_LOAD))
> > - gran = calc_delta_fair(gran, &se->load);
> >
> > - if (pse->vruntime + gran < se->vruntime)
> > + if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
> > resched_task(curr);
> > }
> >
>
> Most curious; are you sure its not a bisection problem?
Quite sure.
> Does ppc32 (or your instance thereof) have a high resolution
> sched_clock()?
I'm not sure (FWIW, we did get support for NO_HZ and HIGH_RES_TIMERS in
2.6.24-rc as well, but playing with these config options and even
reverting the code didn't seem to have any effect), can someone from the
linuxppc-dev list answer this?
> Another question, do you have:
> CONFIG_FAIR_GROUP_SCHED=y
>
> if so, does flipping that off have any effect?
I tried both, no difference that I could tell.
Is there any debugging information I could provide from running the test
on kernels built from at and before the change in question?
Thanks,
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
