Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!merk!alliant!cantrell
From: cantrell@Alliant.COM (Paul Cantrell)
Newsgroups: comp.realtime
Subject: Re: Predicting Execution Times for Processors with caches
Message-ID: <3795@alliant.Alliant.COM>
Date: 10 Apr 90 20:29:03 GMT
References: <765@telesoft.com> <15630004@hp-lsd.COS.HP.COM>
Reply-To: cantrell@alliant.Alliant.COM (Paul Cantrell)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 28

In article <15630004@hp-lsd.COS.HP.COM> dave@hp-lsd.COS.HP.COM (David C. Mueller) writes:
>stated, changes in the flow of code (preempting) does play havoc
>with the contents of the caches.  If my understanding is correct,
>changing the execution flow is roughly the same as starting with an
>empty cache (i.e. where the code picks up execution is not in the
>cache).  If this is true, then a worst case execution time for that
>stream of code can be modeled by running the code in the target
>system with the caches flushed at the beginning of the run.

Depending on the design of the cache in question, assuming that a random
state cache is the same as an empty cache is not a safe assumption, nor
will it result in identical execution times.

One possibility which comes to mind is that a non-writethru cache which
has modified (dirty) data from some other (preempted) thread in it has to
write that modified data back to memory as new data is brought in. A
flushed cache would thus run faster since it has no dirty data to write
back to memory.

I can also believe that some prefetch algorithms would cause some wildly
different behavior in some cases where the access pattern differed because
of old cached data versus a flushed cache.

In general, I'm of the belief that caches and realtime don't mix, but that
we are stuck with them because they are so cost effective with the current
generations of system.

					Paul Cantrell