From: Thomas Gleixner <tglx@linutronix.de>
To: Bill Huey <bhuey@lnxw.com>
Cc: dwalker@mvista.com, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@osdl.org>,
amakarov@ru.mvista.com, ext-rt-dev@mvista.com,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Ext-rt-dev] Re: [ANNOUNCE] Linux 2.6 Real Time Kernel
Date: Tue, 12 Oct 2004 23:32:18 +0200 [thread overview]
Message-ID: <1097616738.19549.160.camel@thomas> (raw)
In-Reply-To: <20041012212408.GA28707@nietzsche.lynx.com>
On Tue, 2004-10-12 at 23:24, Bill Huey wrote:
> On Tue, Oct 12, 2004 at 02:12:01PM -0700, Bill Huey wrote:
> > On Tue, Oct 12, 2004 at 09:46:34PM +0200, Thomas Gleixner wrote:
> > > enter_critical_section(TYPE, &var, &flags, whatever);
> > > leave_critical_section(TYPE, &var, flags, whatever);
> >
> > FreeBSD uses these things, but it they create severe pipeline stalls
> > since they toggle interrupt flags on entry and exit. The current scheme
> > in Linux with preempt_count use to be a curse when I was working on an
> > equivalent implementation of there stuff at:
You missed the point. TYPE decides whether to toggle interrupts or not.
It's a generic function equivivalent, which identifies sections of code,
which must be protected. The grade of protection is defined in TYPE.
> > http://mmlinux.sf.net
>
> Duh, I didn't finish the sentence. I meant this method above is nasty
> filled with pipeline stalls. Don't know if that's what were saying, but
> non-preemptable critical sections denoted by preempt_count must have some
> kind of conceptual overlap with local_irq* functions. I use to curse the
> seperation of the two since it made my own conception irregular, but I
> have come to the conclusion that using relatively something light weight
> like preempt_count() for that functionality instead. That's what I
> meant. :)
I dont see a drawback in the proposal of enter_critical_section and
leave_critical_section conversion.
They indicate a none preemptible region, which must be protected in one
or another way. Which way is choosen, must be evaluated by the
programmer.
There are several grades from preempt_disable over mutexes, spinlocks
and irq blocking. All those grades allow different implementations for
different goals.
Systems which are optimized for througput will use other mechanisms than
systems which are optimized for guaranteed repsonse times.
There is no generic sulotion available for those problems.
But having a generic identifiable expression is more suitable for
improvements, than struggling with substitutions of x,y and z.
tglx
next prev parent reply other threads:[~2004-10-12 21:40 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-09 5:59 [ANNOUNCE] Linux 2.6 Real Time Kernel Sven-Thorsten Dietrich
2004-10-09 6:40 ` Lee Revell
2004-10-09 7:33 ` Daniel Walker
2004-10-09 7:42 ` Lee Revell
2004-10-09 23:40 ` Matthias Urlichs
2004-10-09 8:52 ` Lee Revell
2004-10-09 23:20 ` Dave Hansen
2004-10-09 23:24 ` Lee Revell
2004-10-09 10:51 ` Måns Rullgård
2004-10-09 13:15 ` Måns Rullgård
2004-10-09 21:20 ` Lee Revell
2004-10-09 21:35 ` Måns Rullgård
2004-10-09 21:37 ` Lee Revell
2004-10-09 21:45 ` Måns Rullgård
2004-10-09 21:55 ` Lee Revell
2004-10-09 22:21 ` Måns Rullgård
2004-10-09 23:52 ` Lee Revell
2004-10-10 0:05 ` Måns Rullgård
2004-10-10 0:45 ` Lee Revell
2004-10-10 1:05 ` Måns Rullgård
2004-10-10 1:09 ` Lee Revell
2004-10-10 0:43 ` Micha Feigin
2004-10-10 1:08 ` Måns Rullgård
2004-10-09 17:41 ` Karim Yaghmour
2004-10-09 18:30 ` Lee Revell
2004-10-09 21:26 ` stefan.eletzhofer
2004-10-09 19:30 ` Lee Revell
2004-10-09 19:38 ` Måns Rullgård
2004-10-09 21:38 ` stefan.eletzhofer
2004-10-09 19:47 ` Lee Revell
2004-10-09 20:11 ` Karim Yaghmour
2004-10-09 20:14 ` Lee Revell
2004-10-09 20:53 ` Karim Yaghmour
2004-10-09 20:59 ` Lee Revell
2004-10-09 20:20 ` Robert Love
2004-10-09 20:25 ` Lee Revell
2004-10-10 1:15 ` Lee Revell
2004-10-10 8:46 ` Ingo Molnar
2004-10-10 19:41 ` Daniel Walker
2004-10-10 19:46 ` Ingo Molnar
2004-10-10 21:20 ` Andrew Morton
2004-10-10 21:59 ` Ingo Molnar
2004-10-11 17:53 ` Daniel Walker
2004-10-11 20:49 ` Ingo Molnar
2004-10-11 21:44 ` Sven Dietrich
2004-10-11 21:54 ` Ingo Molnar
2004-10-11 23:05 ` Sven Dietrich
2004-10-12 5:50 ` Ingo Molnar
2004-10-14 5:09 ` Dipankar Sarma
2004-10-14 7:18 ` Ingo Molnar
2004-10-15 14:59 ` Paul E. McKenney
2004-10-15 15:45 ` Ingo Molnar
2004-10-15 16:40 ` Paul E. McKenney
2004-10-15 16:45 ` Paul E. McKenney
2004-10-17 17:12 ` Ingo Molnar
2004-10-12 18:50 ` Daniel Walker
2004-10-12 19:46 ` [Ext-rt-dev] " Thomas Gleixner
2004-10-12 20:31 ` Sven Dietrich
2004-10-12 20:37 ` Thomas Gleixner
2004-10-13 0:30 ` George Anzinger
2004-10-12 21:12 ` Bill Huey
2004-10-12 21:24 ` Bill Huey
2004-10-12 21:32 ` Thomas Gleixner [this message]
2004-10-12 23:13 ` Bill Huey
2004-10-12 21:41 ` Sven Dietrich
2004-10-12 22:57 ` Bill Huey
2004-10-12 23:17 ` Adam Heath
2004-10-12 23:36 ` Lee Revell
2004-10-12 23:25 ` Thomas Gleixner
2004-10-13 2:02 ` K.R. Foley
2004-10-13 13:39 ` Martijn Sipkema
2004-10-13 13:26 ` La Monte H.P. Yarroll
2004-10-13 15:04 ` Martijn Sipkema
2004-10-13 14:55 ` Kurt Wall
2004-10-13 14:52 ` Christoph Hellwig
2004-10-13 15:56 ` Lee Revell
2004-10-13 16:13 ` Robert Love
2004-10-13 17:14 ` Martijn Sipkema
2004-10-13 3:55 ` Bill Huey
2004-10-12 22:00 ` Thomas Gleixner
2004-10-12 22:36 ` Bill Huey
2004-10-12 23:10 ` Thomas Gleixner
2004-10-12 23:33 ` Bill Huey
2004-10-12 23:37 ` Thomas Gleixner
2004-10-12 23:52 ` Bill Huey
2004-10-13 0:59 ` Valdis.Kletnieks
2004-10-10 12:21 ` John Richard Moser
2004-10-10 17:26 ` Lee Revell
2004-10-10 18:45 ` John Richard Moser
2004-10-10 20:20 ` Ingo Molnar
2004-10-10 20:44 ` John Richard Moser
2004-10-10 17:29 ` Daniel Walker
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=1097616738.19549.160.camel@thomas \
--to=tglx@linutronix.de \
--cc=akpm@osdl.org \
--cc=amakarov@ru.mvista.com \
--cc=bhuey@lnxw.com \
--cc=dwalker@mvista.com \
--cc=ext-rt-dev@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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