Re: RT cache management

Jeff Millar (jeff@wa1hco.mv.com)
Sun, 21 Jun 1998 20:35:41 -0400

At 11:38 PM 6/19/98 -0400, you wrote:
>I'd be curious to hear what he really means. 10-30ms is really quite
>soft RT, and if you've got that much time to spare, it sounds like
>he's actually talking about paging, not caching. after all, no cache
>miss takes more than ~150 ns, whereas a page miss is going to cost
>10 ms or so. and of course, mlock is the traditional (hardly new)
>way to avoid page misses, as someone already mentioned on linux-kernel.
>the only cache involved is the TLB, but a miss there should only
>cost a trip into the kernel, a few microseconds...
>regards, mark hahn.
>
Interesting question....but I'm not too sure what I mean. The question
comes from a very good hardware engineer who works with real time kernels
in a multiprocessor environment. Not PC-style shared memory processors,
but ones that have high speed local memory on-board plus access to each
other's memory via an interconnect bus. The system design currently runs a
RT OS on each processor, for example VxWorks, and different but cooperating
applications on the processors. The interconnect bus supports shared
memory and mailbox style interrupts. The system doesn't support cache
coherency so applications need to turn off caching on shared memory. The
system also has I/O memory space that doesn't need caching.

The comment about needing cache control came up as I made one of my regular
suggestions to look at Linux as a replacement for the RTOS's. Our customer
community has begun to ask for a protected mode, virtual memory OS while
preserving the ability to examine all code for safety issues. Except for
I/O interrupts, task scheduling generally runs on a periodic basis at 10 ms
or slower....I agree that fits a soft real time definition. Hardware IRQ's
have maybe 100 us latency requirements but that seems doable under Linux
for the numbers I've seen.

Given the goal of World Domination(tm), it seems that we should look at
significant markets where Linux fits or almost fits. Linux has several key
advantages in a safety sensitive environment.

Transparency: If cryptographic reliability only comes from peer review, I
suggest that safety has the same characteristics.

Robustness: Crash proof

Dynamic Range: Lots of hardware and coding styles supported

So given all these advantages, a feature allegedly needed in a potential
market raises my curiosity.

Recalling the questions: What cache control features do RTOS's have that
Linux doesn't? Does Linux have another approach to achieve the benefits of
cache control? Do applications really need cache control?

thanks,

jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu