Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc

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:

quoted

810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
Author: Peter Zijlstra [off-list ref]
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 [off-list ref]
    Signed-off-by: Ingo Molnar [off-list ref]

: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