Hi Nilay,
Great work indeed! All we need now is a model of an ethernet switch for
some serious-scale parallelism :-)
Andreas
On 03/02/2013 22:53, Steve Reinhardt ste...@gmail.com wrote:
Excellent! Congratulations!
Steve
On Sun, Feb 3, 2013 at 11:16 AM, Nilay ni...@cs.wisc.edu wrote:
The
Ah ok, I see the problem. I'm still not thrilled, but if it's needed I
guess we'll just have to go ahead.
Do we need both the left and right shift? (and is there any chance a
multiplication/division might do instead?)
Andreas
On 01/02/2013 17:23, Nilay ni...@cs.wisc.edu wrote:
On Fri,
On Mon, February 4, 2013 2:38 am, Andreas Hansson wrote:
Ah ok, I see the problem. I'm still not thrilled, but if it's needed I
guess we'll just have to go ahead.
Do we need both the left and right shift? (and is there any chance a
multiplication/division might do instead?)
Currently both
On Sun, 3 Feb 2013, Steve Reinhardt wrote:
Excellent! Congratulations!
Steve
On Sun, Feb 3, 2013 at 11:16 AM, Nilay ni...@cs.wisc.edu wrote:
The netperf test is running. It was good that Ali brought up this email
from 5-6 years back. The very first error I encountered was due to the
One additional idea, to make the classic cache model able to tell the
different kinds of cache misses, non-shared (compulsory, capacity and
conflicts) as well as shared (true or false sharing). Then run workloads to
demonstrate, this should tie in well with the course.
Jack Harvard
On Fri, Feb
Hi Nilay,
That is awesome! If I understand then you have two
systems communicating together over an ethernet link. I would suggest
that this might be a good time for a checkpoint, getting the patches in
state that are good, deciding on a threading model, and getting the
first pass committed.
I agree, this seems like a good time to clean things up and get them
committed, and ideally create a regression test too.
My preference for the next step after that is to start doing some
intra-node parallelization, which would mean doing to some internal
interconnect what was done to the
On Jan. 24, 2013, 9:14 a.m., Andreas Sandberg wrote:
What's the point of the avoidQuiesceLiveLock flag? Is there anything
preventing us from doing a squashAfter whenever there is an interrupt
pending and interrupts are turned on again?
Ali Saidi wrote:
You will be throwing away
Hi Tony,
I had a quick look and was unable to reproduce it myself. Could you
check if it is still a problem and send me your kernel binary in that
case?
I suspect that the problem is that there are cases when we don't reset
the memReq[tid] pointer when a request is has been squashed. Could you
Amin,
I've attached a patch that solves the first of your problems. It is also
available in my fixes [1] branch. I haven't been able to figure out
what's causing the second one.
Could you send me the command line you use when you trigger the problem?
Do you have a minimal (small) test code
On Jan. 24, 2013, 9:14 a.m., Andreas Sandberg wrote:
What's the point of the avoidQuiesceLiveLock flag? Is there anything
preventing us from doing a squashAfter whenever there is an interrupt
pending and interrupts are turned on again?
Ali Saidi wrote:
You will be throwing away
Hi Andreas,
Thanks for taking the time for fixes. I have already applied the same patch
to fix the first problem. So this should fix the problem.
To regenerate the second problem, I have to send you a lot of my patches
because I have highly modified gem5. Since others have not reported such a
12 matches
Mail list logo
