Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Real Time/Cache
Message-ID: <11190@pt.cs.cmu.edu>
Date: 25 Nov 90 23:21:21 GMT
Organization: Carnegie-Mellon University, CS/RI
Lines: 32


One of the interesting problems in real-time systems, is finding
the guaranteed-not-to-exceed execution time of a piece of code.

Caches make the problem nastier. First, you would hope that a cache
full of another task's stuff, is no slower than an empty cache. 

Next, if you assume interrupts, you pretty well have a take the
cache-disabled timing as your worst case. There is an out: you can
prefill the cache and freeze it: but I don't think it's commonly
done. Or, you can scrap interrupts, use non-preemptive scheduling,
and assume that each scheduling event trashes the whole cache.

I recently heard a new answer, which I thought I'd pass along. The
idea is to segment the cache(s), so that some tasks have the
exclusive use of parts of the cache(s). Those tasks are now immune to
interference from other tasks, and perhaps even from interrupts.
Their worst-case times are just their standalone times, on a machine
with a small cache. [Yes, I am ignoring shared data, multilevel
caches, assignment, task switching, etc.]

The suggested support hardware would put (say) four address lines
through four 4:1 muxes.  This would carve the cache into 16 segments,
and a sort of PID would enable some power-of-2 number of these
segments.

The cost? In logic, not much. In time - well, one pre-set-up 4:1-mux
delay on some of the cache-line-select path. Does anyone care to say
how much of a hit that would be on their favorite machine? Or is
there a better way to get a similar effect?
-- 
Don		D.C.Lindsay