From: george anzinger <george@mvista.com>
To: Andi Kleen <ak@muc.de>
Cc: Ian Collinson <icollinson@imerge.co.uk>,
"'Andrew Morton'" <akpm@zip.com.au>, Robert Love <rml@tech9.net>,
Mike Kravetz <kravetz@us.ibm.com>,
linux-kernel@vger.kernel.org, andrea@suse.de
Subject: Re: realtime scheduling problems with 2.4 linux kernel >= 2.4.10
Date: Wed, 05 Jun 2002 11:05:12 -0700 [thread overview]
Message-ID: <3CFE52D8.1A36682F@mvista.com> (raw)
In-Reply-To: <C0D45ABB3F45D5118BBC00508BC292DB09C99A@imgserv04> <20020605141755.A1410@averell>
Andi Kleen wrote:
>
> On Wed, Jun 05, 2002 at 01:53:06PM +0200, Ian Collinson wrote:
>
> >
> > Are there any potentially negative consequences of this fix, apart from
> > those already mentioned?
>
> I don't think so.
>
> It could still fail when you install a prio=99, SCHED_FIFO process.
>
> > I certainly vote for this feature being preserved, as it is extremely useful
> > for debugging realtime priority apps. FYI, we narrowed it down to breaking
> > in either 2.4.10-pre11 or pre12.
>
> That was when the low latency console changes went in. Before that console
> switches could interrupt scheduling for a long time, causing problems
> for other realtime people. The change was to move the expensive parts
> of the console switch to keventd.
So that means that, with the above change to prio 99, we
reintroduce the latency problem, only now it is in a task
(keventd) and not an interrupt? (I know, I know, the work
has to be done somewhere. At least this way we can control
what priority level it is done at. I.e. this is a step in
the right direction. I just what folks to be aware of the
latency issue and where it is.)
For what its worth, you can change the priority of keventd
AFTER a system is up. Robert Love's real time tools contain
a program (rt I think) that will do this for you. Just
follow the URL for preemption in my sig. file and look
around.
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2002-06-05 18:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-05 11:53 realtime scheduling problems with 2.4 linux kernel >= 2.4.10 Ian Collinson
2002-06-05 12:17 ` Andi Kleen
2002-06-05 18:05 ` george anzinger [this message]
2002-06-05 18:13 ` Robert Love
-- strict thread matches above, loose matches on Subject: below --
2002-05-30 17:54 Ian Collinson
2002-05-31 18:28 ` Mike Kravetz
2002-05-31 19:41 ` Andrea Arcangeli
2002-06-01 17:05 ` Andi Kleen
2002-06-03 16:03 ` Mike Kravetz
2002-06-03 20:08 ` Andrew Morton
2002-06-03 20:13 ` Robert Love
2002-06-03 21:09 ` Andrew Morton
2002-06-03 21:07 ` Andrea Arcangeli
2002-06-03 20:12 ` Andi Kleen
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=3CFE52D8.1A36682F@mvista.com \
--to=george@mvista.com \
--cc=ak@muc.de \
--cc=akpm@zip.com.au \
--cc=andrea@suse.de \
--cc=icollinson@imerge.co.uk \
--cc=kravetz@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@tech9.net \
/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