Off hand I would say yes, queuing up a second request behind one that
caused a table walk makes sense. Since there should only be one other
request, just having a variable for the on deck request should be
sufficient instead of a full blown queue. Please let me know if you
think otherwise. I'll think about it some more and let you know if I
change my mind, but I think that makes sense.
Gabe
Quoting Joel Hestness <[email protected]>:
Hi,
I am currently running a benchmark in X86_FS timing mode (single or
multicore) that crashes due to the page table walker. On a data write (or
read) instruction that causes TimingSimpleCPU::write to split the TLB access
into two accesses (cpu/simple/timing.cc:~560), if the first TLB access
misses, it causes the page table walker to start a walk and its state =
Waiting. Since the second access happens immediately
in TimingSimpleCPU::write, if the second request also misses, it causes
another walk that fails the (state == Ready) assertion in
X86ISA::Walker::start (arch/x86/pagetable_walker.cc:~316).
Seems this is a corner case of a corner case, namely, an unaligned (split)
data access, whose split TLB accesses both miss. It doesn't look like there
is any code to handle the situation yet, and I'm hoping to get some guidance
on how to address it.
It seems to me that since this only happens on a TLB miss, that the TLB or
walker should be able to handle the multiple requests. I see that in the
ARM code, the page table walker has a queue of walks that are currently in
flight (I'm having trouble convincing myself that the queues can't conflict
when multiple walks are in flight :\). Would it make sense to have similar
state queuing in the x86 page table walker?
Thanks,
Joel
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Texas - Austin
http://www.cs.utexas.edu/~hestness
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
