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....