From: ludovic fernandez <ludovic.fernandez@sun.com>
To: Roger Larsson <roger.larsson@norran.net>
Cc: Daniel Phillips <phillips@innominate.de>,
george anzinger <george@mvista.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.0-prerelease: preemptive kernel.
Date: Thu, 04 Jan 2001 15:16:04 -0800 [thread overview]
Message-ID: <3A550433.52982189@sun.com> (raw)
In-Reply-To: <3A53D863.53203DF4@sun.com> <3A5427A6.26F25A8A@innominate.de> <3A5437A1.F540D794@sun.com> <01010423104900.01080@dox>
Roger Larsson wrote:
> On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
>
> > I'm not convinced a full preemptive kernel is something
> > interesting mainly due to the context switch cost (actually mmu contex
> > switch).
>
> It will NOT be fully, it will be mostly.
> You will only context switch when a higher prio thread gets runnable, two
> ways:
> 1) external intterupt waking higher prio process, same context swithes as
> when running in user code. We won't get more interrupts.
> 2) wake up due to something we do. Not that many places, mostly due to
> releasing syncronization objects (spinlocks does not count).
>
> If this still is a problem, we can select to only preemt to processes running
> RT stuff. SCHED_FIFO and SCHED_RR by letting them set need_resched to 2...
> > What about only preemptable kernel threads ?
>
> No, it won't help enough.
>
This is not the point I was trying to make .....
So far we are talking about real time behaviour. This is a very interesting/exciting
thing and we all agree it's a huge task which goes much more behind
just having a preemptive kernel.
I'm not convinced that a preemptive kernel is interesting for apps using
the time sharing scheduling, mainly because it is not deterministic and the
price of a mmu conntext switch is still way to heavy (that's my 2 cents belief
anyway).
But, having a preemptive kernel could be interesting for an another issue.
More and more the linux kernel is using the concept of kernel threads to
defer part of the processing. Right now they are not preemptable and one
has to put explicit preemption points. I believe this solution doesn't fly in
the long term (the code changes, the locking design changes and the
preemption points become irrelevant). They could be preemptable because
they have a way of being deterministic (preemption disable) and they
are lightweight to schedule since they don't use a mmu context.
Ludo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-01-04 23:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-04 1:56 [PATCH] 2.4.0-prerelease: preemptive kernel ludovic fernandez
2001-01-04 7:35 ` Daniel Phillips
2001-01-04 8:11 ` Andi Kleen
2001-01-04 12:32 ` Anton Blanchard
2001-01-04 12:44 ` Andi Kleen
2001-01-04 21:54 ` Nigel Gamble
2001-01-04 21:39 ` Nigel Gamble
2001-01-04 22:09 ` Andi Kleen
2001-01-04 22:28 ` Nigel Gamble
2001-01-04 8:43 ` ludovic fernandez
2001-01-04 22:10 ` Roger Larsson
2001-01-04 23:16 ` ludovic fernandez [this message]
2001-01-05 0:10 ` Nigel Gamble
2001-01-05 0:36 ` ludovic fernandez
2001-01-05 0:45 ` Andi Kleen
2001-01-05 1:13 ` Alan Olsen
2001-01-05 5:29 ` george anzinger
2001-01-05 6:45 ` ludovic fernandez
2001-01-05 8:10 ` george anzinger
2001-01-04 21:28 ` Nigel Gamble
2001-01-04 9:00 ` David Woodhouse
2001-01-04 16:17 ` Rik van Riel
2001-01-04 20:06 ` Nigel Gamble
2001-01-04 20:36 ` ludovic fernandez
2001-01-05 0:56 ` Daniel Phillips
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=3A550433.52982189@sun.com \
--to=ludovic.fernandez@sun.com \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@innominate.de \
--cc=roger.larsson@norran.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