Messages in this thread | | | Date | Sun, 21 Jun 1998 20:35:41 -0400 | From | Jeff Millar <> | Subject | Re: RT cache management |
| |
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
| |