From: Andrew Morton <akpm@linux-foundation.org>
To: markh@compro.net
Cc: linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@tv-sign.ru>,
Mark Hounschell <dmarkh@cfl.rr.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: floppy.c soft lockup
Date: Wed, 6 Jun 2007 10:28:28 -0700 [thread overview]
Message-ID: <20070606102828.752bf955.akpm@linux-foundation.org> (raw)
In-Reply-To: <4666B2A4.7090603@compro.net>
On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <markh@compro.net> wrote:
> >
> > As far as a 100% CPU bound task being a valid thing to do, it has been
> > done for many years on SMP machines. Any kernel limitation on this
> > surely must be considered a bug?
> >
>
> Could someone authoritatively comment on this? Is a SCHED_RR/SCHED_FIFO
> 100% Cpu bound process supported in an SMP env on Linux? (vanilla or -rt)
It will kill the kernel, sorry.
The only way in which we can fix that is to allow kernel threads to preempt
rt-priority userspace threads. But if we were to do that (to benefit the
few) it would cause _all_ people's rt-prio processes to experience glitches
due to kernel activity, which we believe to be worse.
So we're between a rock and a hard place here.
If we really did want to solve this then I guess the kernel would need some
new code to detect a 100%-busy rt-prio process and to then start premitting
preemption of it for kernel thread activity. That detector would need to
be smart enough to detect a number of 100%-busy rt-prio processes which are
yielding to each other, and one rt-prio process which keeps forking others,
etc. It might get tricky.
next prev parent reply other threads:[~2007-06-06 17:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 17:31 floppy.c soft lockup Mark Hounschell
2007-05-31 5:46 ` Andrew Morton
2007-05-31 14:28 ` Mark Hounschell
2007-05-31 17:06 ` Oleg Nesterov
2007-05-31 18:01 ` Mark Hounschell
2007-05-31 18:44 ` Mark Hounschell
2007-05-31 19:22 ` Oleg Nesterov
2007-05-31 20:18 ` Mark Hounschell
2007-06-01 9:51 ` Mark Hounschell
2007-06-01 11:00 ` Oleg Nesterov
2007-06-01 14:10 ` Mark Hounschell
2007-06-01 15:16 ` Oleg Nesterov
2007-06-01 17:11 ` Mark Hounschell
2007-06-01 18:36 ` Oleg Nesterov
2007-06-01 19:52 ` Mark Hounschell
2007-06-02 12:30 ` Oleg Nesterov
2007-06-02 20:44 ` Mark Hounschell
2007-06-03 8:14 ` Oleg Nesterov
2007-06-04 14:00 ` Mark Hounschell
2007-06-06 13:12 ` Mark Hounschell
2007-06-06 17:28 ` Andrew Morton [this message]
2007-06-07 1:31 ` Matt Mackall
2007-06-07 10:18 ` Mark Hounschell
2007-06-07 14:25 ` Matt Mackall
2007-06-08 9:54 ` Mark Hounschell
2007-06-13 16:17 ` Oleg Nesterov
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=20070606102828.752bf955.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dmarkh@cfl.rr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markh@compro.net \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
/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.