I totally agree! It's just not obvious to me how to do that with a
(reasonable) amount of effort.

I've talked to Hongil about how he was reproducing the problem and (as with
a lot of the problems we run into around here) it went something like: "I
was using 2.32.??? version of Linux. Running parsec with exactly 5 threads
pinned to CPUs 0,1,2,4,8. I have modified the program in X way. And if I
change anything about my setup the problem doesn't manifest."

It's not obvious to me how to turn this into a test. Do you have any
suggestions? Maybe using the trace and replay mechanisms?

Jason

On Tue, Sep 15, 2015 at 10:29 AM Andreas Hansson <[email protected]>
wrote:

> Hi Jason,
>
> I’d like to at least understand if there is an issue (and preferably have
> a test case that hits it).
>
> Andreas
>
> On 15/09/2015 16:25, "gem5-dev on behalf of Jason Lowe-Power"
> <[email protected] on behalf of [email protected]> wrote:
>
> >Hi all,
> >
> >I fear I'm going to get a reputation for repeating the same thing over and
> >over again here, but...
> >
> >To me, this seems like (yet another) a problem with our testing
> >infrastructure. From what I gather from the conversation, it's unknown
> >whether this affects the other CPU models. Andreas, do you have any
> >concrete idea of how to tell if this affects the other CPUs? If not, I
> >don't know how it's possible for Hongil to deal with this. Unfortunately,
> >problems like this often only come up in complicated and difficult to
> >reproduce configurations.
> >
> >IMO, another issue here is that Hongil spent many hours struggling to find
> >the issue with the O3 CPU. He then posted a solution to the problem he
> >found. Should he also be responsible for putting in the effort to a)
> >understand the other CPU models and b) figure out the best way to solve
> >the
> >issue? I personally don't think so, but I suppose it's up for debate.
> >
> >/2 cents
> >
> >Jason
> >
> >On Tue, Sep 15, 2015 at 10:09 AM Andreas Hansson <[email protected]
> >
> >wrote:
> >
> >> Hi Nilay,
> >>
> >> No I am saying that if this was a bug in the o3 LSQ, then it is still a
> >> bug in the minor LSQ, and I think that is rather unfortunate, and I
> >>would
> >> have liked both to be fixed at once. The question also applies to the
> >> atomic and timing cpu.
> >>
> >> Andreas
> >>
> >> On 15/09/2015 16:04, "gem5-dev on behalf of Nilay Vaish"
> >> <[email protected] on behalf of [email protected]> wrote:
> >>
> >> >On Tue, 15 Sep 2015, Andreas Hansson wrote:
> >> >
> >> >> Hi Nilay,
> >> >>
> >> >> To me it reads like there is a now a known issue with the MinorCPU,
> >>and
> >> >> an intentional disparity between the O3CPU and MinorCPU. If the split
> >> >> request snoop is really a problem the change should be made to both
> >>the
> >> >> CPU models at once imho.
> >> >>
> >> >
> >> >It seems you are claiming that to begin with MinorCPU and O3CPU had no
> >> >differences at all in their LSQ structures.  If that is the case, why
> >> >have
> >> >separate structures at all.  If we recognize some problem with the
> >>alpha
> >> >ISA, it is not necessary that we fix that problem for other ISAs as
> >>well
> >> >at the same time.
> >> >
> >> >
> >> >--
> >> >Nilay
> >> >_______________________________________________
> >> >gem5-dev mailing list
> >> >[email protected]
> >> >http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> >>
> >> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> >> confidential and may also be privileged. If you are not the intended
> >> recipient, please notify the sender immediately and do not disclose the
> >> contents to any other person, use it for any purpose, or store or copy
> >>the
> >> information in any medium.  Thank you.
> >>
> >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> >> Registered in England & Wales, Company No:  2557590
> >> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
> >>9NJ,
> >> Registered in England & Wales, Company No:  2548782
> >> _______________________________________________
> >> gem5-dev mailing list
> >> [email protected]
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> >_______________________________________________
> >gem5-dev mailing list
> >[email protected]
> >http://m5sim.org/mailman/listinfo/gem5-dev
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2548782
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to