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.
Gabe Vince Weaver wrote: > For some reason, on 32-bit x86 the mmap_start address is very close to the > beginning of the stack. Because of this, benchmarks like gzip that > allocate 64MB using mmap fail (while giving a soewhat obscure "memory > already mapped" pagetable error). > > This patch arbitrarily moves the value down some, the value picked > probably isn't a good one. > > > diff -r 1b22ddf9266a src/arch/x86/process.cc > --- a/src/arch/x86/process.cc Mon Sep 21 23:04:31 2009 -0400 > +++ b/src/arch/x86/process.cc Mon Sep 21 23:05:57 2009 -0400 > @@ -184,7 +184,7 @@ > > // Set up region for mmaps. This was determined empirically and may not > // always be correct. > - mmap_start = mmap_end = (Addr)0xf7ffd000ULL; > + mmap_start = mmap_end = (Addr)0xd7ffd000ULL; > } > > SyscallDesc* > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
