On Jun 30, 2008, at 5:15 PM, Steve Reinhardt wrote:
On Mon, Jun 30, 2008 at 9:11 AM, Ali Saidi [EMAIL PROTECTED] wrote:
The FastAlloc pools and StaticInst cache should clearly be
duplicated.
Why would you want to duplicate the StaticInst cache? It's a
read-mostly structure so you'd only
OK, that makes more sense now. Still seems like in the long term the
right thing is to use a data structure that supports multiple readers
with either per-bucket locks, a reader/writer lock, or some sort of
non-blocking update (has x86 added a compare-and-swap yet?).
They've had cmpxchg
Yes. CMPXCHG on page 98 of volume 3 of the AMD manuals. It says it
supports the lock prefix so I'm assuming it's not otherwise atomic.
Gabe
non-blocking update (has x86 added a compare-and-swap yet?).
___
m5-dev mailing list
m5-dev@m5sim.org
I vote for (1) until it can be shown that it matters. A single pointer
doesn't seem like a big deal, especially since most of the things we
create and destroy frequently aren't SimObjects but other classes.
Ali
On Jun 29, 2008, at 12:23 PM, nathan binkert wrote:
I'm nearly done with the
I vote for (1) until it can be shown that it matters. A single pointer
doesn't seem like a big deal, especially since most of the things we
create and destroy frequently aren't SimObjects but other classes.
Showing that it matters is pretty hard unless you actually do it. A
profile won't
This is probably slightly off topic, but could you explain more
specifically the synchronization event stuff you mention on the wiki
page? It sounds interesting but I can't picture what you're describing.
Gabe
nathan binkert wrote:
I vote for (1) until it can be shown that it matters. A
