Re: [RFC][PATCH] Restricted hard realtime

From: Jon Masters
Date: Sat Oct 23 2004 - 17:08:45 EST


On Sat, 23 Oct 2004 14:24:21 -0700, Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:

> On Sat, Oct 23, 2004 at 10:22:01PM +0200, Thomas Gleixner wrote:

> > On Sat, 2004-10-23 at 12:47 -0700, Paul E. McKenney wrote:

> > I haven't seen an embedded SMP system yet. Focussing this on SMP systems
> > is ignoring the majority of possible applications.

> Seeing SMP support for ARM lead me to believe that this was not too far
> over the edge.

They have an SMP reference implementation, however many folks don't
actually want to go the dual core approach right now for embedded
designs (apparently the increased design complexity isn't worth it).
I've had protracted discussions about this very issue quite recently
indeed. Others will disagree, I'm only basing my statement upon
conversations with various engineers - I think your idea eventually
becomes interesting, but now is not the right moment to be pushing it
yet. People still don't want this now.

Talk to smartphone manufacturers who currently have dual ARM core
designs, one running Linux and the other running an RTOS for the GSM
and phone stuff, and they'll say they actually want to reduce the
design complexity down to a single core. Talking to people suggests
that multicore designs are good in certain situations (such as in the
case above), but in general people aren't yet going to respond to your
way of doing realtime :-) Yes you do have only one OS in there, maybe
that would change opinion, but we're not quite at the point where
everything is multicore so you're not going to convince the masses.

Having said all that, for a different perspective, I hack on ppc
(Xilinx Virtex II Pro) kernel and userspace stuff for some folks that
make high resolution imaging equipment, involving extremely precise
control over a pulsed signal and data acquisition (we're talking
nanosecond/microsecond precision). Since Linux obviously isn't capable
of this level of deterministic response right now we end up farming
out work to a separate core - it's unlikely your approach would
convince the hardware folks, but I guess it might be tempting at some
point in the future. Who knows.

Jon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/