public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: <mgix@mgix.com>
To: <linux-kernel@vger.kernel.org>
Subject: Question about sched_yield()
Date: Sat, 15 Jun 2002 15:15:32 -0700	[thread overview]
Message-ID: <AMEKICHCJFIFEDIBLGOBGEDPCBAA.mgix@mgix.com> (raw)


Hello,

I am seeing some strange linux scheduler behaviours,
and I thought this'd be the best place to ask.

I have two processes, one that loops forever and
does nothing but calling sched_yield(), and the other
is basically benchmarking how fast it can compute
some long math calculation.

When I run the math simulator with nothing else running,
I get the following:

lenslark # ./loop
1.86543 MLoops per sec, sum=0.291969
1.84847 MLoops per sec, sum=1.65587
1.84064 MLoops per sec, sum=1.74601

When I run one instance of the math simulator and
one instance of the sched_yielder, I see the behaviour
I was expecting (and want): all CPU is allocated to the
process that does some actual work:

lenslark # ./yield &
[1] 26316
lenslark #
lenslark # ./loop
1.86502 MLoops per sec, sum=0.291969
1.84868 MLoops per sec, sum=1.65587
1.84035 MLoops per sec, sum=1.74601

and top confirms what I'm seeing: loop gets 99% of
the CPU, and yield gets close to none.

However, when I have two instances of the
sched_yielder running, things start to behave strange:

lenslark # ./yield &
[1] 26350
lenslark # ./yield &
[2] 26351
lenslark # ./loop
0.686901 MLoops per sec, sum=0.291969
0.674352 MLoops per sec, sum=1.65587
0.665542 MLoops per sec, sum=1.74601
0.674117 MLoops per sec, sum=0.407357

and sure enough, top is showing that for
some reason, the sched_yielders get 1/3rd
of the CPU:

26364 root      18   0   364  364   304 R    36.0  0.3   0:04 loop
26351 root      12   0   252  252   204 R    32.2  0.2   0:31 yield
26350 root      14   0   252  252   204 R    31.2  0.2   0:33 yield
26365 root      11   0  1024 1024   812 R     0.3  1.0   0:00 top


Does anyone have a clue as to why this happens ?
Is this the expected behaviour given the current
scheduler algorithm (of which I know nothing :)).

For comparison purposes, I ran the same test on
Win2k+MingWin32, and things behave the way I'd expect
there: no matter how many sched_yielders are running,
loop gets almost all of the CPU, and barely slows down.

I am running on an AMD-K6@400Mhz, on the following kernel:

lenslark # cat /proc/version
Linux version 2.4.18 (root@lenslark.mgix.com) (gcc version 2.96 20000731 (Mandra
ke Linux 8.2 2.96-0.76mdk)) #1 Sun Apr 28 15:25:19 PDT 2002

This kernel was compiled with SMP turned off.

If anyone can explain me what's going on, or even better
how to replicate the behaviour I'm seeing on Win2k, I'd
be very happy. Also, I'm not a subscriber to linux-kernel,
so I'd appreciate a CC.

I've included the source to the two small programs below:

================================= YIELD.CPP

#ifdef linux
#include <sched.h>
main()
{
    while(1)
    {
	sched_yield();
    }
}
#endif


#ifdef WIN32
#include <windows.h>
main()
{
    while(1)
    {
	Sleep(0);
    }
}
#endif

================================= LOOP.CPP
#include <math.h>
#include <stdio.h>
#include <sys/time.h>

#ifdef WIN32
#include <windows.h>
#endif

typedef unsigned long long uint64_t;

uint64_t usecs()
{

#ifdef linux
    struct timeval t;
    gettimeofday(&t,0);

    uint64_t result;
    result= t.tv_sec;
    result*= 1000000;
    result+= t.tv_usec;
    return result;
#endif

#ifdef WIN32
    return 1000*(uint64_t)GetTickCount();
#endif
}

main()
{
    uint64_t t= 0;
    double sum= 0.0;
    uint64_t lastTime= 0;
    uint64_t lastLoops= 0;
    while(t<100000000)
    {
	sum+= sin((double)t);
	if((t%4000000)==0)
	{
	    uint64_t nowTime= usecs();
	    uint64_t nowLoops= t;

	    if(lastTime!=0)
	    {
		double loops= (nowLoops-lastLoops);
		double elapsed= (nowTime-lastTime)/1000000.0;
		fprintf(
		    stderr,
		    "%g MLoops per sec, sum=%g\n",
		    (loops/elapsed)/1000000.0,
		    sum
		);
	    }

	    lastTime= nowTime;
	    lastLoops= nowLoops;
	}
	++t;
    }
    fprintf(stderr,"Sum=%g\n",sum);
}



             reply	other threads:[~2002-06-15 22:15 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-15 22:15 mgix [this message]
2002-06-16 14:43 ` [patch] Re: Question about sched_yield() Ingo Molnar
2002-06-18  0:46 ` David Schwartz
2002-06-18  0:55   ` Robert Love
2002-06-18  1:51     ` mgix
2002-06-18  3:18     ` David Schwartz
2002-06-18  9:36     ` David Schwartz
2002-06-18 16:58       ` Chris Friesen
2002-06-18 17:12         ` Richard B. Johnson
2002-06-18 17:19           ` mgix
2002-06-18 18:01             ` David Schwartz
2002-06-18 18:05               ` mgix
2002-06-18 19:11                 ` David Schwartz
2002-06-18 16:58                   ` Rob Landley
2002-06-18 19:25                   ` Robert Love
2002-06-18 19:53                     ` David Schwartz
2002-06-18 20:12                       ` mgix
2002-06-18 20:42                         ` David Schwartz
2002-06-18 20:47                           ` mgix
2002-06-18 22:00                             ` David Schwartz
2002-06-18 22:28                           ` Ingo Molnar
2002-06-18 20:08                     ` Richard B. Johnson
2002-06-19 11:10                     ` Bill Davidsen
2002-06-19 12:04                       ` Ingo Molnar
2002-06-18 22:43               ` Olivier Galibert
2002-06-18 18:21             ` Richard B. Johnson
2002-06-18 17:13         ` Robert Love
2002-06-18 18:00           ` David Schwartz
2002-06-18 22:45             ` Stevie O
2002-06-19  2:11               ` David Schwartz
2002-06-19  2:52                 ` Stevie O
2002-06-20 20:31               ` David Schwartz
2002-06-18 17:23         ` Rik van Riel
2002-06-18 17:50           ` Chris Friesen
2002-06-18  1:41   ` mgix
2002-06-18  3:21     ` David Schwartz
2002-06-18  3:52       ` mgix
2002-06-18  4:55   ` Ingo Molnar
2002-06-19 11:24     ` Bill Davidsen
2002-06-19 11:47       ` scheduler timeslice distribution, threads, processes. [was: Re: Question about sched_yield()] Ingo Molnar
2002-06-18 18:56   ` Question about sched_yield() Rusty Russell
2002-06-18 19:12     ` David Schwartz
2002-06-18 20:19       ` Rusty Russell
2002-06-18 20:40         ` David Schwartz
2002-06-18 20:42         ` mgix
2002-06-18 22:03           ` David Schwartz
2002-06-18 22:36           ` Ingo Molnar
2002-06-19 11:29     ` Bill Davidsen
2002-06-19 14:03       ` Rusty Russell
2002-06-19 22:25         ` Bill Davidsen
2002-06-19 22:37           ` Ingo Molnar
2002-06-19  2:10   ` jw schultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AMEKICHCJFIFEDIBLGOBGEDPCBAA.mgix@mgix.com \
    --to=mgix@mgix.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox