[lkml]   [2004]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] Restricted hard realtime
Hash: SHA1

Paul E. McKenney wrote:

| Thank you for the background! It has been quite some time since I
| did significant embedded work. Let's just say that I am glad that
| "embedded CPU" no longer means "8-bit CPU"! ;-)

Oh it still does, but those cores tend to get farmed out for PSU
controll or some specific subsystem unless you're "deeply embedded".

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

| Good points. Suppose there was a way to get the hard realtime benefits
| using a slight elaboration of this approach that worked on single-core,
| single-threaded CPUs? Would that be of interest?

I dunno. It might. I think the trouble is that you'll need to convince
people who think they want single core designs that it's not a must.
Although within a little time it'll increasingly be the case that one
has additional cores whether one wants them or not, that's not just yet
even now. Someone will doubtlessly disagree.

| if you are going for the ultimate in response time, you have
| no choice but to run hand-coded assembly language on bare metal (though
| optimizing compilers are improving, so maybe it will soon be hand-coded
| C on bare metal).

Nah. The guys I work with have enough trouble making things time nicely
with precisely coded sequences accounting for every available T state.

| If you are using your computer to digitally modulate
| and synthesize a USA FM radio signal

In this case it's large magnets and probes, but yes. Same concept.

| So, I guess the question is whether 100-microsecond restricted hard
| realtime support in Linux is worth the effort.

Some of the folks I work with think not. I'm not sure yet - many people
seem to be of the opinion that it's not worth it, but we're told that
the Smartphone guys and others without throwaway cores (or to simplify a
design somewhat) really want this. Incidentally, it looks like they'll
be about a bazzion cores in this particular FPGA range before long, so
it'll become increasingly fun finding things for them to do.

| So, again, if there was a way to make this approach work on
| single-threaded single core CPUs, would that be of interest?

I guess it would. But then we've just had a slew of RT implementations
crawl out of the woodwork and wave at us over the past few weeks and
there are three other major RT implementations which combine Linux with
a Microkernel or other external support (RTLinux, RTAI, KURT, etc.).
Perhaps it's worth working on one of the Linux patch projects
(Monta/Ingo/etc.) rather than going all out to implement it all again.

Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.051 / U:0.588 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site