Unfortunately, the stats change in all cases. For (1) the
instructions no longer have IsMemRef set which means the num_refs
changes for all CPUs and the change causes some minor changes in the O3.
With (2) they're half baked, so the models call initiateAcc() but it
doesn't actually initiate the access, so completeAcc() is never called
and thus they aren't counted as part of the instruction count. (2) isn't
ideal since half-calling the initiateAcc() might lead to some problems
down the road.
I'll post a diff today.
Ali
On Tue, 2 Nov 2010
12:18:08 -0700, Steve Reinhardt wrote:
Do you mean (1) or (2)? I
thought that with (1) the stats would not change.
My bias would be (2),
but (1) seems livable enough. In either case it would be nice to put in
a warn_once() if we don't already have one so it's obvious that SW
prefetches are being ignored.
Steve
On Sun, Oct 31, 2010 at 9:45 AM,
Ali Saidi wrote:
Any input? Otherwise I'm going with (1) and have new
stats to go with it.
Ali
On Oct 27, 2010, at 12:02 AM, Ali Saidi
wrote:
> Hmmm... three emails when one should have done. There are
three options:
> 1. Make them actual no-ops (e.g. stop marking them as
mem refs, data prefetch, etc). The instruction count will stay the same
here. The functionality will stay the same. The instructions will be
further away from working -- not that I think anyone will make them work
in the future.
> 2. Leave them in their half bake memop state where
they're memops that never call read() and don't write back anything, so
the instruction count is different since the inst count gets incremented
after the op completes. This is what I currently have.
> 3. Make them
actually work. I've tried to muck with this without success for a while
now.
>
> Ali
>
>
>
> On Oct 26, 2010, at 11:58 PM, Ali Saidi
wrote:
>
>> The other portion of this, is when I try to make them act
like loads, but not actually write a register I break the o3 cpu in ways
that 4 hours has not been able to explain.
>>
>> Ali
>>
>> On Oct
26, 2010, at 10:42 PM, Ali Saidi wrote:
>>
>>> The count gets smaller
because since they don't actually access memory, they never complete and
therefore they never increment the instruction count.
>>>
>>> Ali
>>>
>>> On Oct 26, 2010, at 9:53 PM, Steve Reinhardt wrote:
>>>
>>>>
I vote for updating the stats... it's really wrong that we ignored them
previously.
>>>>
>>>> On Tue, Oct 26, 2010 at 5:47 PM, Ali Saidi
wrote:
>>>> Ok. So next question. With the CPU model treating
prefetches as normal memory instructions the # of instructions changes
for the timing simple cpu because the inst count stat is incremented in
completeAccess(). So, one option is to update the stats to reflect the
new count. The other option would be to stop marking the prefetch
instructions as memory ops in which case they would just execute as nop.
Any thoughts?
>>>>
>>>> Ali
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Oct
24, 2010, at 12:14 AM, Steve Reinhardt wrote:
>>>>
>>>>> No, we've
lived with Alpha prefetches the way they are for long enough
>>>>> now
I don't see where fixing them buys us that much.
>>>>>
>>>>> Steve
>>>>>
>>>>> On Sat, Oct 23, 2010 at 6:13 PM, Ali Saidi wrote:
>>>>>>
Sounds goo to me. I'll take a look at what I need to do to implement it.
Any arguments with the Alpha prefetch instructions staying nops?
>>>>>>
>>>>>> Ali
>>>>>>
>>>>>> On Oct 22, 2010, at 6:52 AM, Steve
Reinhardt wrote:
>>>>>>
>>>>>>> On Tue, Oct 19, 2010 at 11:14 PM, Ali
Saidi wrote:
>>>>>>>>
>>>>>>>> I think the prefetch should be sent
the the TLB unconditionally, and then if the prefetch faults the CPU
should toss the instruction rather than the TLB returning no fault and
the CPU i guess checking if the PA is set?
>>>>>>>>
>>>>>>>> I agree
that we should override the fault in the CPU. Are we violently
agreeing?
>>>>>>>
>>>>>>> OK, it's becoming a little clearer to me
now. I think we're agreeing
>>>>>>> that the TLB should be oblivious to
whether an access is a prefetch or
>>>>>>> not, so that's a start.
>>>>>>>
>>>>>>> The general picture I'd like to see is that once a
prefetch returns
>>>>>>> from the TLB, the CPU does something like:
>>>>>>>
>>>>>>> if (inst->fault == NoFault) {
>>>>>>> access the
cache
>>>>>>> } else if (inst->isPrefetch()) {
>>>>>>> maybe set a
flag if necessary
>>>>>>> inst->fault = NoFault;
>>>>>>> }
>>>>>>>
>>>>>>> ...so basically everywhere else down the pipeline where we check
for
>>>>>>> faults we don't have to explicitly except prefetches from
normal fault
>>>>>>> handling.
>>>>>>>
>>>>>>> If there are points
past this one where we really care to know if a
>>>>>>> prefetch
accessed the cache or not, then maybe we need a flag to
>>>>>>>
remember that (sort of a dynamic version of the NO_ACCESS static
>>>>>>> flag), but I don't know if that's really necessary or not.
Clearly if
>>>>>>> the cache access doesn't happen right there, then we
can add the flag
>>>>>>> and use it later to decide whether to access
the cache.
>>>>>>>
>>>>>>> Anyway, this is the flavor I was going
for... any issues with it?
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
_______________________________________________
>>>> m5-dev mailing
list
>>>> m5-dev@m5sim.org [5]
>>>>
http://m5sim.org/mailman/listinfo/m5-dev [6]
>>>>
>>>>
_______________________________________________
>>>> m5-dev mailing
list
>>>> m5-dev@m5sim.org [7]
>>>>
http://m5sim.org/mailman/listinfo/m5-dev [8]
>>>
>>>
_______________________________________________
>>> m5-dev mailing
list
>>> m5-dev@m5sim.org [9]
>>>
http://m5sim.org/mailman/listinfo/m5-dev [10]
>>>
>>
>>
_______________________________________________
>> m5-dev mailing list
>> m5-dev@m5sim.org [11]
>> http://m5sim.org/mailman/listinfo/m5-dev
[12]
>>
>
> _______________________________________________
> m5-dev
mailing list
> m5-dev@m5sim.org [13]
>
http://m5sim.org/mailman/listinfo/m5-dev [14]
>
Links:
------
[1]
mailto:sa...@umich.edu
[2] mailto:sa...@umich.edu
[3]
mailto:sa...@umich.edu
[4] mailto:sa...@umich.edu
[5]
mailto:m5-dev@m5sim.org
[6] http://m5sim.org/mailman/listinfo/m5-dev
[7]
mailto:m5-dev@m5sim.org
[8] http://m5sim.org/mailman/listinfo/m5-dev
[9]
mailto:m5-dev@m5sim.org
[10]
http://m5sim.org/mailman/listinfo/m5-dev
[11]
mailto:m5-dev@m5sim.org
[12]
http://m5sim.org/mailman/listinfo/m5-dev
[13]
mailto:m5-dev@m5sim.org
[14] http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
