Thanks Korey.
Yeah inability to run > 32 cores on 32-bit machines, and inability to
run > 64 cores on 64-bit machines is the same issue, so I guess the STL
bitsets solution should fix this problem too.
Thanks,
Tushar
On 5/28/2011 2:34 AM, Korey Sewell wrote:
Tushar,
There should be an earlier thread about this issue (or one very similar). A
symptom of this issue is the inability to run large systems on 32-bit
machines.
I think what we wanted to do is use STL bitsets here (check that thread for
details). I would do it myself but I wont have time until after the tutorial
for Ruby optimizations.
Could you check that thread and let us know whether that would or would not
solve this problem?
On Sat, May 28, 2011 at 2:21 AM, Tushar Krishna<tus...@csail.mit.edu>wrote:
Hi all,
I think src/mem/ruby/common/Set.hh has a bug.
It has the following lines:
static const int LONG_BITS = std::numeric_limits<long>::digits;
static const int INDEX_SHIFT = LONG_BITS == 64 ? 6 : 5;
Since "long" by default is signed, LONG_BITS will always be 31 or 63,
depending on the machine (not 32 or 64).
This means that INDEX_SHIFT will always be set to 5.
I tried setting --num-cpus to 128 and ran a tester, and observed a bunch of
glibc errors.
A gdb backtrace pointed me to Set.hh (via ruby/common/NetDest.hh).
I changed "long" to "unsigned long" and that fixed the issue.
Is this a fine fix and should I send out a patch?
Thanks,
Tushar
_______________________________________________
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
