From: Bill Huey (hui) <billh@gnuppy.monkey.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Darren Hart <darren@dvhart.com>,
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>,
"Bill Huey (hui)" <billh@gnuppy.monkey.org>
Subject: Re: RT task scheduling
Date: Sat, 8 Apr 2006 00:54:30 -0700 [thread overview]
Message-ID: <20060408075430.GA19403@gnuppy.monkey.org> (raw)
In-Reply-To: <20060408072530.GA14364@elte.hu>
On Sat, Apr 08, 2006 at 09:25:30AM +0200, Ingo Molnar wrote:
> > to the contrary, the "RT overload" code in the -rt tree does strict,
> > system-wide RT priority scheduling. That's the whole point of it.
>
> so after this "clarification of terminology" i hope you are in picture
> now, so could you please explain to me what you meant by:
> > > You should consider for a moment to allow for the binding of a
> > > thread to a CPU to determine the behavior of a SCHED_FIFO class task
> > > instead of creating a new run category. [...]
>
> to me it still makes no sense, and much of the followups were based on
> this. Or were you simply confused about what the scheduling code in -rt
> does precisely? Did that get clarified now?
The last time I looked at it I thought it did something pretty simplistic
in that it just dumped any RT thread to another CPU but didn't do it in
a strict manner with regard to priority. Maybe that's changed or else I
didn't pay attention to it that as carefully as I thought.
As far as CPU binding goes, I'm wanting a method of getting around the
latency of the rt overload logic in certain cases at the expense of
rebalancing. That's what I ment by it.
bill
next prev parent reply other threads:[~2006-04-08 7:54 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
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 [this message]
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=20060408075430.GA19403@gnuppy.monkey.org \
--to=billh@gnuppy.monkey.org \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.