As it turns out, the issue stemmed from entries in the icacheBuffer_
structure in CPUController not being properly cleared. This issue is now
resolved.
-Addison
On 06/04/2012 03:31 PM, Addison Mayberry wrote:
Greetings,
I'm encountering an interesting problem with the l1i cache and I'm not
sure how to address it. I'm currently doing some work to determine the
number of cache lines perturbed by a system call. My somewhat
simplistic method for doing it is to, when the call is encountered,
back up all of the data in the cache, reset the cache, let the system
call run, and on return, count the number of lines altered, then
restore the cache to its pre-syscall state.
The issue I'm seeing is that, once every few runs, the l1i cache stops
loading new data during a syscall. That is to say, I reset the l1i
cache when the call starts, let the call run, and at the end of the
call, the l1i cache is still completely blank. Once this starts
happening, it happens every single time the syscall occurs afterwards
(i.e., if I call getsockname 100 times, and it happens on the 10th
call, it will happen every single time after that as well). Also,
whenever this happens, I have observed that the number of cycles that
the system call takes to process decreases by about 30%.
It seems to me that the l1i cache should constantly be receiving new
lines so long as code is running, but I don't know for sure. Is this
behavior expected or is it caused by some glitch in MARSS or by my
instrumenting procedure?
I know it's kind of an odd issue, but if anyone could give me any
information on where to start looking into it, it'd be very
appreciated. Thanks in advance for any help.
Sincerely,
Addison
_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
