> On Feb. 3, 2015, 9:37 p.m., Brandon Potter wrote: > > The patch seems like a landmine for an unsuspecting user as it would be > > difficult to diagnose if swap space is exhausted. It will probably be > > evident that memory exhaustion caused the runtime error (segmentation > > fault), but tracking down the cause to this patch will probably be > > non-trivial (maybe?). For a user, the memory allocation failure from > > insufficient swap space would probably be preferable to a hard to diagnose > > segmentation fault. > > > > Even though it is ugly, maybe it's best to add #if 0 / #endif around the > > code to allow someone to find this later on and enable the feature if they > > need it (with a warning about the segmentation fault). The memory > > allocation failure will point the user to the code in this patch.
Fair point. An option would be to not use the flag for "sensible" sizes, perhaps <16 GB or so, and adopt it for larger sizes with a warning? - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2624/#review5821 ----------------------------------------------------------- On Feb. 3, 2015, 7:57 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2624/ > ----------------------------------------------------------- > > (Updated Feb. 3, 2015, 7:57 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10689:568e9a533cf0 > --------------------------- > mem: mmap the backing store with MAP_NORESERVE > > This patch ensures we can run simulations with very large simulated > memories (at least 64 TB based on some quick runs on a Linux > workstation). In essence this allows us to efficiently deal with > sparse address maps without having to implement a redirection layer in > the backing store. > > This opens up for run-time errors if we eventually exhausts the hosts > memory and swap space, but this should hopefully never happen. > > > Diffs > ----- > > src/mem/physical.cc 7639c17357dc > > Diff: http://reviews.gem5.org/r/2624/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
