> I think the right solution is
> that for each of these we should either change it into the first model or
> eliminate the bypass option altogether and always do a separately scheduled
> callback.
>
> I think the distinction of having main() call y() directly rather than
> x_cb() is potentially i
Yea, in the default hierarchical snoop-based model there's only one modified
copy at a time. If the L2 knows that an L1 has a modified copy then it
should not respond. If that's not known for sure from the coherence state
whether the L1 or L2 should respond then that is problematic.
Steve
On Tu
I actually looked at the code a bit this time; and I have a hypothesis that
the problem arises from two similar but fundamentally different models of
"bypassing" potential event-based delays:
main() {
x_will_callback = x();
if (!x_will_callback) y();
}
x() {
if (...) { sched_callback(
There is the original problem of reads and writes happening in place
and hence getting things out of order, but there's also a problem with
the call stack getting arbitrarily deep if you manage to continuously
avoid anything that has a delay. The example I mentioned would be if
you have a m
Depending on the issue and complexity of that issue, you might expect
the turnaround time on a email to vary in length.
I actually had a draft response, but was confused and didnt want to
get "ranted on" for not knowing what I was talking about so I held
back.
Here is a draft of what I was going
* do-regression: qsub timed out, retrying locally
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/
