linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Darren Hart <darren@dvhart.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"Stultz, John" <johnstul@us.ibm.com>,
	Peter Williams <pwil3058@bigpond.net.au>,
	"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: RT task scheduling
Date: Thu, 6 Apr 2006 15:35:27 -0700	[thread overview]
Message-ID: <200604061535.28952.darren@dvhart.com> (raw)
In-Reply-To: <200604061116.02429.darren@dvhart.com>

On Thursday 06 April 2006 11:16, you wrote:
> On Thursday 06 April 2006 00:37, Ingo Molnar wrote:
> > * Darren Hart <darren@dvhart.com> wrote:
> > > My last mail specifically addresses preempt-rt, but I'd like to know
> > > people's thoughts regarding this issue in the mainline kernel.  Please
> > > see my previous post "realtime-preempt scheduling - rt_overload
> > > behavior" for a testcase that produces unpredictable scheduling
> > > results.
> >
...

> > in any case, i'll check your -rt testcase to see why it fails.
>
> Just as an example, here is the output a failing test case on a 4way
> machine running 2.6.16-rt13 (a successful run would have a final ball
> position of 0).
>
> [root@box sched_football]# ./sched_football 4 10
> Starting 4 offense threads at priority 15
> Starting 4 defense threads at priority 30
> Starting referee thread
> Game On (10 seconds)!
> Game Over!
> Final ball position: 5
> [root@box sched_football]#
>
> --Darren


On a related note, I tried observing the rt stats in /proc/stats while running 
sched_football on 2.6.16-rt13.  The entire log is nearly a MB so I placed it 
on my website for reference 
(http://www.dvhart.com/~dvhart/sched_football_stats.log), an excerpt follows:

---------------------

The following is the output of sched_football run with 1 thread for offense 
and 1 thread for defense on a 4 way machine.  The ball position is irrelevant 
in this case since there are more CPUs than threads (they should all be able 
to run).  What is disturbing is that over the entire run, I never see RT 
tasks on every CPU.  Even though there are usually 5 total runnnable threads, 
we constantly see groupings of 2 and 3 on the runqueues while the others have 
no running rt tasks.

Looking back, I should have added a sleep to the loop - oops - still, I think 
the data is interesting and suggests a problem with sceduling RT tasks across 
all available CPUs.  Does this seem like a valid test to everyone?  Is there 
perhaps some explanation as to why this would be expected (when the cat 
process get's to read the proc information or something) ?

# ./sched_football 1 60
Starting 1 offense threads at priority 15
Starting 1 defense threads at priority 30
Starting referee thread
Game On (60 seconds)!
Game Over!
Final ball position: 20359767

# while true; do clear; cat /proc/stat | grep rt >> sched_football_stats.log; 
done

sched_football_stats.log
------------------------------
rt_overload_schedule: 57768
rt_overload_wakeup:   157501
rt_overload_pulled:   13722934
rt_nr_running(0): 0
rt_nr_running(1): 0
rt_nr_running(2): 0
rt_nr_running(3): 0
rt_overload: 0
rt_overload_schedule: 57769
rt_overload_wakeup:   157514
rt_overload_pulled:   13722937
rt_nr_running(0): 0
rt_nr_running(1): 2
rt_nr_running(2): 3
rt_nr_running(3): 0
rt_overload: 2
...
rt_overload_schedule: 57774
rt_overload_wakeup:   157738
rt_overload_pulled:   13722941
rt_nr_running(0): 0
rt_nr_running(1): 2
rt_nr_running(2): 4
rt_nr_running(3): 0
rt_overload: 2
...
rt_overload_schedule: 57791
rt_overload_wakeup:   158650
rt_overload_pulled:   13722964
rt_nr_running(0): 0
rt_nr_running(1): 2
rt_nr_running(2): 0
rt_nr_running(3): 3
rt_overload: 2
...
rt_overload_schedule: 57808
rt_overload_wakeup:   166924
rt_overload_pulled:   13722973
rt_nr_running(0): 0
rt_nr_running(1): 0
rt_nr_running(2): 0
rt_nr_running(3): 2
rt_overload: 1
rt_overload_schedule: 57808
rt_overload_wakeup:   166927
rt_overload_pulled:   13722973
rt_nr_running(0): 0
rt_nr_running(1): 0
rt_nr_running(2): 0
rt_nr_running(3): 0
rt_overload: 0

---------------------

  reply	other threads:[~2006-04-06 22:35 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-06  3:25 RT task scheduling Darren Hart
2006-04-06  4:19 ` Peter Williams
2006-04-06 17:24   ` Darren Hart
2006-04-06 23:02     ` Peter Williams
2006-04-06  7:37 ` Ingo Molnar
2006-04-06 14:55   ` Darren Hart
2006-04-06 18:16   ` Darren Hart
2006-04-06 22:35     ` Darren Hart [this message]
2006-04-07 22:58       ` Vernon Mauery
2006-04-06 23:06   ` Peter Williams
2006-04-07  3:07   ` Bill Huey
2006-04-07  7:11     ` Ingo Molnar
2006-04-07  8:39       ` Bill Huey
2006-04-07  9:11         ` Bill Huey
2006-04-07  9:19         ` Ingo Molnar
2006-04-07 10:39           ` Bill Huey
2006-04-07 10:51             ` Ingo Molnar
2006-04-07 11:14               ` Bill Huey
2006-04-07 11:29                 ` Ingo Molnar
2006-04-07 22:18                   ` Bill Huey
2006-04-07 14:56             ` Darren Hart
2006-04-07 21:06               ` Bill Huey
2006-04-07 22:37                 ` Darren Hart
2006-04-07 23:36                   ` Bill Huey
2006-04-08  3:01                     ` Steven Rostedt
2006-04-08  4:28                       ` Vernon Mauery
2006-04-08  4:45                         ` Steven Rostedt
2006-04-08  7:16                 ` Ingo Molnar
2006-04-08  7:25                   ` Ingo Molnar
2006-04-08  7:54                     ` Bill Huey
2006-04-08  8:03                       ` Ingo Molnar
2006-04-08 10:02                         ` Bill Huey
2006-04-08  0:11   ` Peter Williams
2006-04-07  9:23 ` Bill Huey
2006-04-09 13:16 ` Ingo Molnar
2006-04-09 17:25   ` Darren Hart
2006-04-09 18:31     ` Ingo Molnar

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=200604061535.28952.darren@dvhart.com \
    --to=darren@dvhart.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pwil3058@bigpond.net.au \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).