From: rgo...@atnf.CSIRO.AU (Richard Gooch)
Subject: Scheduler latency
Date: 1998/01/21
Message-ID: <199801210609.RAA04281@vindaloo.atnf.CSIRO.AU>#1/1
X-Deja-AN: 317938754
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel


  Hi, all. I've noticed that the scheduler in linux 2.1.79 seems a lot
slower than the one in 2.0.25. Results of timing sched_yield(2):

PPro/180 running 2.1.79:
SCHED_OTHER class:	56 microseconds
SCHED_FIFO class:	3  microseconds

P133 running 2.0.25:
SCHED_OTHER class:	4  microseconds
SCHED_FIFO class:	4  microseconds

Does this result surprise anyone? I had hoped that the 2.1.x series
was faster :-/

				Regards,

					Richard....
===============================================================================
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/time.h>
#include <unistd.h>
#include <sched.h>
#include <errno.h>

#define DEFAULT_ITERS 1000
#define ERRSTRING strerror (errno)

int main (int argc, char **argv)
{
    int count;
    int num_iters = DEFAULT_ITERS;
    long time_taken;
    struct timeval start_time, stop_time;
    struct sched_param sp;

    if (argc > 1) num_iters = atoi (argv[1]);
    if (geteuid () == 0)
    {
	sp.sched_priority = 99;
	if (sched_setscheduler (0, SCHED_FIFO, &sp) != 0)
	{
	    fprintf (stderr,
		     "Error setting scheduling class to SCHED_FIFO\t%s\n",
		     ERRSTRING);
	    exit (1);
	}
	fprintf(stderr,
		"Timing %d iterations of sched_yield(2) in class SCHED_FIFO\n",
		num_iters);
    }
    else
    {
	fprintf (stderr,
		 "Timing %d iterations of sched_yield(2) in class SCHED_OTHER\n",
		 num_iters);
    }
    if (gettimeofday (&start_time, NULL) != 0)
    {
	fprintf (stderr, "Error getting start time\t%s\n", ERRSTRING);
	exit (1);
    }
    for (count = 0; count < num_iters; ++count)
    {
	sched_yield ();
    }
    if (gettimeofday (&stop_time, NULL) != 0)
    {
	fprintf (stderr, "Error getting stop time\t%s\n", ERRSTRING);
	exit (1);
    }
    time_taken = (stop_time.tv_sec - start_time.tv_sec) * 1000000;
    time_taken += (stop_time.tv_usec - start_time.tv_usec);
    fprintf (stderr, "Total time: %ld us\titeration time: %ld us\n",
	     time_taken, time_taken / num_iters);
}   /*  End Function main  */

From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: Scheduler latency
Date: 1998/01/21
Message-ID: <Pine.LNX.3.95.980121095242.5898L-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 318092607
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980121000146.3389A-100000@marvin.transmeta.com>
Newsgroups: muc.lists.linux-kernel




On Wed, 21 Jan 1998, Jauder Ho wrote:
> 
> benchsrv%jauderho% uname -a ; ./a.out
> Linux benchsrv.transmeta.com 2.1.62 #5 Mon Nov 3 15:36:46 PST 1997 i686
> Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
> Total time: 42874 us    iteration time: 42 us

The above is a dual SMP..

> sw130%jauderho%  uname -a ; ./a.out
> Linux sw130.transmeta.com 2.1.80 #1 Sun Jan 18 21:36:55 PST 1998 i686
> Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
> Total time: 18989 us    iteration time: 18 us

As is sw130..

> marvin%jauderho% uname -a ; ./a.out
> Linux marvin.transmeta.com 2.1.80 #4 Tue Jan 20 19:34:24 PST 1998 i686 unknown
> Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
> Total time: 192339 us   iteration time: 192 us

But "marvin" is a single, right?

> Linus, were there scheduler changes merged into the final 80 patch coz sw130 is
> running the pre-80 patch.

No, there should be almost no difference between what you run on marvin
and what runs on sw130 (apart from the SMP irq stuff, but the fact that
you can run at all on marvin means that you compiled marvin as UP,
right?). BUT sw130 is a dual, which allows us to schedule one process on
one CPU and run another on the other - they can actually partly overlap.
That would certainly explain the difference in times..

> On Wed, 21 Jan 1998, Richard Gooch wrote:
> 
> >   Hi, all. I've noticed that the scheduler in linux 2.1.79 seems a lot
> > slower than the one in 2.0.25. Results of timing sched_yield(2):
> > 
> > PPro/180 running 2.1.79:
> > SCHED_OTHER class:	56 microseconds
> > SCHED_FIFO class:	3  microseconds
> > 
> > P133 running 2.0.25:
> > SCHED_OTHER class:	4  microseconds
> > SCHED_FIFO class:	4  microseconds

2.0.25 doesn't actually do anything that all when you run "sched_yield()". 
There was a missing "need_resched = 1" in the 2.0.x series, so
sched_yield() actually didn't do anything at all. Which is what you want
if you want to benchmark how fast sched_yield() is, but it is NOT what you
want if you actually want to _do_ sched_yield().. 

		Linus

From: jaude...@transmeta.com (Jauder Ho)
Subject: Re: Scheduler latency
Date: 1998/01/21
Message-ID: <Pine.LNX.3.96.980121103710.17403D-100000@calcium.transmeta.com>#1/1
X-Deja-AN: 318124241
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980121095242.5898L-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel


On Wed, 21 Jan 1998, Linus Torvalds wrote:

> 
> 
> On Wed, 21 Jan 1998, Jauder Ho wrote:
> > 
> > benchsrv%jauderho% uname -a ; ./a.out
> > Linux benchsrv.transmeta.com 2.1.62 #5 Mon Nov 3 15:36:46 PST 1997 i686
> > Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
> > Total time: 42874 us    iteration time: 42 us
> 
> The above is a dual SMP..

	AFAIK I remember it being a single. And I remember setting it up :)

> 
> As is sw130..

	it is SMP

> But "marvin" is a single, right?

	it is a single, but so is my home machine. which gives

turtle%jauderho% ./a.out
Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
Total time: 45862 us    iteration time: 45 us

	however it seems to isolated to marvin only which is kinda strange..,
coz sodium which is another single running 2.1.80 returns 

calcium%i386-linux% rsh na ./a.out
Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
Total time: 39899 us    iteration time: 39 us

marvin and turtle are compiled as UP, right. I have had problems with SMP
kernels not liking the fact that i have a SMP board with only one cpu.

--Jauder

> No, there should be almost no difference between what you run on marvin
> and what runs on sw130 (apart from the SMP irq stuff, but the fact that
> you can run at all on marvin means that you compiled marvin as UP,
> right?). BUT sw130 is a dual, which allows us to schedule one process on
> one CPU and run another on the other - they can actually partly overlap.
> That would certainly explain the difference in times..
> 

ADVISORY: There Is an Extremely Small but Nonzero Chance That, Through a
Process Known as 'Tunneling,' This Message May Spontaneously Disappear
from Its Present Location and Reappear at Any Random Place in the
Universe, Including Your Neighbour's Kitchen. The Author Will Not Be
Responsible for Any Damages or Inconveniences That May Result.

From: rgo...@atnf.CSIRO.AU (Richard Gooch)
Subject: Re: Scheduler latency
Date: 1998/01/21
Message-ID: <199801212031.HAA03177@vindaloo.atnf.CSIRO.AU>#1/1
X-Deja-AN: 318148782
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980121095242.5898L-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel


Linus Torvalds writes:
> 
> 
> On Wed, 21 Jan 1998, Jauder Ho wrote:
> > 
> > benchsrv%jauderho% uname -a ; ./a.out
> > Linux benchsrv.transmeta.com 2.1.62 #5 Mon Nov 3 15:36:46 PST 1997 i686
> > Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
> > Total time: 42874 us    iteration time: 42 us
> 
> The above is a dual SMP..
> 
> > sw130%jauderho%  uname -a ; ./a.out
> > Linux sw130.transmeta.com 2.1.80 #1 Sun Jan 18 21:36:55 PST 1998 i686
> > Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
> > Total time: 18989 us    iteration time: 18 us
> 
> As is sw130..
> 
> > marvin%jauderho% uname -a ; ./a.out
> > Linux marvin.transmeta.com 2.1.80 #4 Tue Jan 20 19:34:24 PST 1998 i686 unknown
> > Timing 1000 iterations of sched_yield(2) in class SCHED_OTHER
> > Total time: 192339 us   iteration time: 192 us
> 
> But "marvin" is a single, right?
> 
> > Linus, were there scheduler changes merged into the final 80 patch coz sw130 is
> > running the pre-80 patch.
> 
> No, there should be almost no difference between what you run on marvin
> and what runs on sw130 (apart from the SMP irq stuff, but the fact that
> you can run at all on marvin means that you compiled marvin as UP,
> right?). BUT sw130 is a dual, which allows us to schedule one process on
> one CPU and run another on the other - they can actually partly overlap.
> That would certainly explain the difference in times..
> 
> > On Wed, 21 Jan 1998, Richard Gooch wrote:
> > 
> > >   Hi, all. I've noticed that the scheduler in linux 2.1.79 seems a lot
> > > slower than the one in 2.0.25. Results of timing sched_yield(2):
> > > 
> > > PPro/180 running 2.1.79:
> > > SCHED_OTHER class:	56 microseconds
> > > SCHED_FIFO class:	3  microseconds
> > > 
> > > P133 running 2.0.25:
> > > SCHED_OTHER class:	4  microseconds
> > > SCHED_FIFO class:	4  microseconds
> 
> 2.0.25 doesn't actually do anything that all when you run "sched_yield()". 
> There was a missing "need_resched = 1" in the 2.0.x series, so
> sched_yield() actually didn't do anything at all. Which is what you want
> if you want to benchmark how fast sched_yield() is, but it is NOT what you
> want if you actually want to _do_ sched_yield().. 

Hm. I didn't realise that. Yesterday when I checked the sources I was
looking at 2.0.33 :-/
Note that both the machines I tested this on have two CPUs and have
SMP=1. Running the test in a single CPU (SMP=0) PPro 200 running
2.0.31:
SCHED_OTHER:	13 microseconds

				Regards,

					Richard....

From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: Scheduler latency
Date: 1998/01/21
Message-ID: <Pine.LNX.3.95.980121123608.464C-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 318136599
Sender: muc.de!l-linux-kernel-owner
References: <199801212031.HAA03177@vindaloo.atnf.CSIRO.AU>
Newsgroups: muc.lists.linux-kernel




On Thu, 22 Jan 1998, Richard Gooch wrote:
> > > > slower than the one in 2.0.25. Results of timing sched_yield(2):
> > > > 
> > > > PPro/180 running 2.1.79:
> > > > SCHED_OTHER class:	56 microseconds
> > > > SCHED_FIFO class:	3  microseconds
> > > > 
> > > > P133 running 2.0.25:
> > > > SCHED_OTHER class:	4  microseconds
> > > > SCHED_FIFO class:	4  microseconds
> > 
> > 2.0.25 doesn't actually do anything that all when you run "sched_yield()". 
> > There was a missing "need_resched = 1" in the 2.0.x series, so
> > sched_yield() actually didn't do anything at all. Which is what you want
> > if you want to benchmark how fast sched_yield() is, but it is NOT what you
> > want if you actually want to _do_ sched_yield().. 
> 
> Hm. I didn't realise that. Yesterday when I checked the sources I was
> looking at 2.0.33 :-/
> Note that both the machines I tested this on have two CPUs and have
> SMP=1. Running the test in a single CPU (SMP=0) PPro 200 running
> 2.0.31:
> SCHED_OTHER:	13 microseconds

Ok, 2.0.31 should have the sched_yield() fix already, so now the numbers
are ok. Can you also test a SMP-2.0.31 in order to be able to compare
validly against the 2.1.79 case? It is certainly possible that this has
gotten slower, but the 2.0.25 numbers aren't something we can compare
against (essentially, all kernels before 2.0.31 are fundamentally broken
wrt sched_yield()). 

			Linus

From: rgo...@atnf.CSIRO.AU (Richard Gooch)
Subject: Re: Scheduler latency
Date: 1998/01/22
Message-ID: <199801220119.MAA00414@vindaloo.atnf.CSIRO.AU>#1/1
X-Deja-AN: 318222454
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980121124211.464E-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel


Linus Torvalds writes:
> 
> 
> On Thu, 22 Jan 1998, Richard Gooch wrote:
> > 
> > How about 2.0.33? I've got that tree on disc.
> 
> Sure, anything later than or equal to 2.0.31 should be ok in this regard
> (obviously not the early 2.1.x series, they had the same problem).

OK, here's some results for you:

Dual PPro/180 running 2.1.79-SMP:
SCHED_OTHER class:	56 microseconds
SCHED_FIFO class:	3  microseconds

Dual PPro/180 running 2.1.79-UP:
SCHED_OTHER class:	40 microseconds
SCHED_FIFO class:	2  microseconds


Dual PPro/180 running 2.0.33-SMP:
SCHED_OTHER class:	14 microseconds
SCHED_FIFO class:	7  microseconds

Dual PPro/180 running 2.0.33-UP:
SCHED_OTHER class:	9  microseconds
SCHED_FIFO class:	4  microseconds

BTW: what news on my MTRR patch?

				Regards,

					Richard....