Re: 2.5.64-mm6, a new test case for scheduler interactivity problems

Re: 2.5.64-mm6, a new test case for scheduler interactivity problems

[Felipe Alfaro Solana]

----- Original Message ----- 
From: Charles Baylis <cb-lkml@fish.zetnet.co.uk> 
Date: 	Thu, 13 Mar 2003 22:01:02 +0000 
To: linux-kernel@vger.kernel.org 
Subject: 2.5.64-mm6, a new test case for scheduler interactivity problems 
 
> I've just installed 2.5.64-mm6, and I've tried out the new improved  
> scheduler and it's definately not there yet. I can easily cause ogg  
> playback to skip (for example) by changing virtual desktop in windowmaker  
> to busy konqueror window. X is not reniced (has a nice level of 0) 
 
I cannot reproduce your problems... same scenario: 2.5.64-mm6, 
KDE desktop, XFree86 4.3.0 (no nice). 
 
> My experience suggests that skips occur when more than one interactive task  
> starts to become a CPU hog, for example X and konqueror can be idle for  
> long periods, and so become interactive, but during an intensive redraw  
> they briefly behave as CPU hogs but maintain their interactive bonus this  
> means that ogg123 has to wait until the hogs complete their timeslice  
> before being scheduled. 
 
Can't reproduce... 
 
> My test case tries to reproduce this by creating a number of tasks which  
> alternate between being 'interactive' and CPU hogs. On my Celery 333 laptop  
> it can sometimes cause skips with only 1 child, and is pretty much  
> guaranteed to cause skips with more child tasks. 
 
I have a Pentium III Mobile 700 Mhz, anyways... 
 
> To compile use 'gcc -o thud thud.c' 
>  
> To reproduce, I: 
> run ogg123 somefile.ogg in one xterm 
> run ./thud 1 in another xterm 
 
No ways... I start ogg123 to reproduce a very long file and then, 
launched ./thud 20 (yes, 20, but I also tried with 2 and 1), but 
ogg123 doesn't skip. No way, I can't make it skip. 
 
Try doing 
 
echo 50 > /proc/sys/sched/max_timeslice 
 
and see if it helps. 
Thanks! 
 
   Felipe 
 
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

2.5.64-mm6, a new test case for scheduler interactivity problems

[Charles Baylis]

Hi all

I've just installed 2.5.64-mm6, and I've tried out the new improved 
scheduler and it's definately not there yet. I can easily cause ogg 
playback to skip (for example) by changing virtual desktop in windowmaker 
to busy konqueror window. X is not reniced (has a nice level of 0)

It's several months since I last ran a 2.4 kernel on this machine, but as I 
remember it did not skip when changing desktops.

My experience suggests that skips occur when more than one interactive task 
starts to become a CPU hog, for example X and konqueror can be idle for 
long periods, and so become interactive, but during an intensive redraw 
they briefly behave as CPU hogs but maintain their interactive bonus this 
means that ogg123 has to wait until the hogs complete their timeslice 
before being scheduled.

My test case tries to reproduce this by creating a number of tasks which 
alternate between being 'interactive' and CPU hogs. On my Celery 333 laptop 
it can sometimes cause skips with only 1 child, and is pretty much 
guaranteed to cause skips with more child tasks.

To compile use 'gcc -o thud thud.c'

To reproduce, I:
run ogg123 somefile.ogg in one xterm
run ./thud 1 in another xterm

The music will often skip shortly after thud displays "running....". If not, 
try ./thud 2 or more.

My setup is celery 333 Sony Vaio 128MB, Debian sid, XFree86 4.2.1, gcc 3.2, 
preempt. (Side note: the PCMCIA changes in 2.5.64-mm6 seem to work OK with 
3c574_cs)

Charlie

=============================================
/* thud.c */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/time.h>
#include <time.h>
#include <sched.h>

/* These are used as strings so that strcmp can be used as a delay loop */
char *s1, *s2;

/* 20000 is fine on my 333MHz Celeron. Adjust so that system time is not
   excessive */
#define DELAY 20000

void busy_wait(long sec, long usec)
{
  struct timeval tv;
  long long end_usec;
  gettimeofday(&tv,0);
  end_usec=(long long)(sec+tv.tv_sec)*1000000 + tv.tv_usec+usec;
  while (((long long)tv.tv_sec*1000000 + tv.tv_usec) < end_usec)
  {
    gettimeofday(&tv,0);
    strcmp(s1,s2); /* yuck */
  }
}

int main(int argc, char**argv)
{
  struct timespec st={10,50000000};
  int n=DELAY;
  int parent=1;

  if (argc<2) {fprintf(stderr,"Syntax: thud <children>\n"); return 0; }

  s1=malloc(n);
  s2=malloc(n);
  memset(s1,33,n);
  memset(s2,33,n);
  s1[n-1]=0;
  s2[n-1]=0;

  n=atoi(argv[1]);
  fprintf(stderr,"starting %d children\n",n);
  for (; n>0; n--)
    if (fork()==0) { sched_yield(); parent=0; break; }
  while (1)
  {
    nanosleep(&st, 0);
    if (parent) printf("running...");
    if (parent) fflush(stdout);
    busy_wait(6,0);
    if (parent) printf("done\n");
  }
  return 0;
}

Re: 2.5.64-mm6, a new test case for scheduler interactivity problems

[Mike Galbraith]

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

At 10:01 PM 3/13/2003 +0000, Charles Baylis wrote:

>Hi all
>
>I've just installed 2.5.64-mm6, and I've tried out the new improved
>scheduler and it's definately not there yet. I can easily cause ogg
>playback to skip (for example) by changing virtual desktop in windowmaker
>to busy konqueror window. X is not reniced (has a nice level of 0)
>
>It's several months since I last ran a 2.4 kernel on this machine, but as I
>remember it did not skip when changing desktops.
>
>My experience suggests that skips occur when more than one interactive task
>starts to become a CPU hog, for example X and konqueror can be idle for
>long periods, and so become interactive, but during an intensive redraw
>they briefly behave as CPU hogs but maintain their interactive bonus this
>means that ogg123 has to wait until the hogs complete their timeslice
>before being scheduled.
>
>My test case tries to reproduce this by creating a number of tasks which
>alternate between being 'interactive' and CPU hogs. On my Celery 333 laptop
>it can sometimes cause skips with only 1 child, and is pretty much
>guaranteed to cause skips with more child tasks.

Greetings,

Nice test case.  I don't have sound capability on my linux box, but your 
test case makes it fail the window wiggle test horribly.  I fiddled with it 
a bit, and convinced it to "stop doing that please".  Does the attached 
(experimental butchery) help your box's sp-sp-speach im-p-p-pediment?

         -Mike 

[-- Attachment #2: bk5_sched.diff --]
[-- Type: application/octet-stream, Size: 1033 bytes --]

--- linux-2.5.64-bk5/kernel/sched.c.org	Wed Mar 12 08:51:11 2003
+++ linux-2.5.64-bk5/kernel/sched.c	Fri Mar 14 15:27:12 2003
@@ -72,7 +72,7 @@
 #define PRIO_BONUS_RATIO	25
 #define INTERACTIVE_DELTA	2
 #define MAX_SLEEP_AVG		(10*HZ)
-#define STARVATION_LIMIT	(10*HZ)
+#define STARVATION_LIMIT	(1*HZ)
 #define NODE_THRESHOLD		125
 
 /*
@@ -356,6 +356,8 @@
 		 * spends sleeping, the higher the average gets - and the
 		 * higher the priority boost gets as well.
 		 */
+		if (sleep_time > MAX_TIMESLICE)
+			sleep_time = MAX_TIMESLICE;
 		sleep_avg = p->sleep_avg + sleep_time;
 
 		/*
@@ -397,6 +399,8 @@
 		rq->nr_uninterruptible++;
 	dequeue_task(p, p->array);
 	p->array = NULL;
+	if (p->sleep_avg)
+		p->sleep_avg--;
 }
 
 /*
@@ -1249,6 +1253,8 @@
 	if (!--p->time_slice) {
 		dequeue_task(p, rq->active);
 		set_tsk_need_resched(p);
+		if (TASK_INTERACTIVE(p) && p->sleep_avg > MIN_TIMESLICE)
+			p->sleep_avg -= MIN_TIMESLICE;
 		p->prio = effective_prio(p);
 		p->time_slice = task_timeslice(p);
 		p->first_time_slice = 0;

Re: 2.5.64-mm6, a new test case for scheduler interactivity problems

[Mike Galbraith]

At 03:34 PM 3/14/2003 +0100, Mike Galbraith wrote:
>At 10:01 PM 3/13/2003 +0000, Charles Baylis wrote:
>>My test case tries to reproduce this by creating a number of tasks which
>>alternate between being 'interactive' and CPU hogs. On my Celery 333 laptop
>>it can sometimes cause skips with only 1 child, and is pretty much
>>guaranteed to cause skips with more child tasks.
>
>Greetings,
>
>Nice test case.  I don't have sound capability on my linux box, but your 
>test case makes it fail the window wiggle test horribly.  I fiddled with 
>it a bit, and convinced it to "stop doing that please".  Does the attached 
>(experimental butchery) help your box's sp-sp-speach im-p-p-pediment?

P.S.  If you try this, change STARVATION_LIMIT from 1*HZ to 
2*MAX_TIMESLICE.  With that, I can run a make -j5 bzImage, irman with fixed 
mem_load, thud 3 and kasteroids with no trouble at ALL on my 128mb 
p3/500.  The only time things get ugly is when memload fires up.  It 
allocates 72mb and scribbles to it... a bit much for a 128mb box with 
_this_ load ;-)  Even then, swapping like heck, kasteroids is playable most 
of the time.

Without the patch, irman's process load starves everyone to death, and thud 
3 utterly destroys interactivity.  YMMV of course (it _is_ an experiment... 
might even explode;)

         -Mke