[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 -

    -----END PGP SIGNATURE-----
    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.024 / U:18.956 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site