Quoting Vince Weaver <[email protected]>: > On Tue, 22 Sep 2009, Gabe Black wrote: >> This value was actually based off how Linux set up an actual process on >> a real machine. We have a tool that runs processes on a real machine and >> compares their execution with M5. I calibrated those constants to make >> the execution match exactly all the way through. That said, there might >> be some complication that's not being taken into account. On the other >> hand, that's 0xffffe000 - 0xf7ffd000 ~= 135 MB of space which should be >> enough. Maybe our simplistic policy of never actually reusing munmapped >> memory is bighting us. > > Well, I can say that the value is never going to be that on a real 32-bit > x86 machine, because the kernel is mapped from 0xc0000000-0xffffffff. > It is true things are a bit different running 32-bit binaries on a 64-bit > kernel as it frees out the upper gigabyte of address space. > > Many of the spec2k benchmarks use more than 128M of mmap space, and the > spec2k6 ones use upwards of a gigabyte. > > In my experience on real hardware the 32-bit mmap space starts around > 0xd0000000 somewhere, but this gets changed up when you have mmap() > randomization turned on as most newer kernels do. > > Vince > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
It was on a 64 bit machine with address space randomization explicitly turned off. Would you mind checking what strace says mmap is returning? I'm curious if it fails over to some other area if it runs out of space. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
