Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas <kernel@kolivas.org>]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

On Sat, 12 Jul 2003 09:37, Christian Axelsson wrote:
> On Fri, 2003-07-11 at 16:30, Con Kolivas wrote:
> > On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
> > > Ok complies and boot fine
> > >
> > > BUT... after loading X up and gnome-theme-manager I start clicking
> > > around abit.. then gnome-theme-manager starts eating 99.9% CPU (prolly
> > > a bug in the program). Problem here is that the machine stops
> > > responding to input, at first I can move mouse around (but Im stuck in
> > > the current focused X-client) and later it all stalls... Cant even get
> > > in via SSH. Ive put on a top before repeating this showing
> > > gnome-theme-manager eating all CPU-time (PRI 15/NICE 0) and load
> > > showing ~55% user ~45% system.
> > >
> > > Anything I can do to help debugging?
> >
> > Can you try this patch instead which should stop the machine from getting
> > into a deadlock? I dont think I have found the problem but at least it
> > should be easier to diagnose without the machine locking up.
>
> Deadlock is gone but problem is still there.
> Running processes (state R) keep running smooth until they try to access
> any resource (ie. xmms keeps playing the current file but gets stuck
> when trying to open next one, top keeps running with full
> interactivity). Spawning new processes is impossible.
> I had top running over SSH and when I exited I managed to type 1 char
> then it hung up. A note is that sometimes the load is ~45% user ~55%
> system instead of ~55% user and ~45% system. There are always those
> values.
> I tried to reproduce by creating a while(1){} loop but it runs smooth.
>
> Any suggestions on methods to debug this?

Difficult apart from what you're already describing. The interesting point is 
the waiting for something that makes it hang, which reminds me of the 
parent-child waiting problem and is likely to be similar. The thing about iso 
tasks is they are by definition always active so they always get reinserted 
into the active array. However if they are waiting for something and are 
constantly preempting that something it will never happen. Can you try the 
attached diff which always puts them on the expired array if they run out of 
timeslice to see if that helps? This is not the ideal fix, but I need to see 
if it is the problem.

Con

[-- Attachment #2: patch-SIfix --]
[-- Type: text/x-diff, Size: 582 bytes --]

diff -Naurp linux-2.5.75-mm1/kernel/sched.c linux-2.5.75-test/kernel/sched.c
--- linux-2.5.75-mm1/kernel/sched.c	2003-07-12 10:04:21.000000000 +1000
+++ linux-2.5.75-test/kernel/sched.c	2003-07-12 10:05:34.000000000 +1000
@@ -1333,7 +1333,7 @@ void scheduler_tick(int user_ticks, int 
 		p->time_slice = task_timeslice(p);
 		p->first_time_slice = 0;
 
-		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) {
+		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq) || iso_task(p)) {
 			if (!rq->expired_timestamp)
 				rq->expired_timestamp = jiffies;
 			enqueue_task(p, rq->expired);