On 06/13/2018 03:54 PM, Emilio G. Cota wrote: > So, what to do based on all this? > > I think the current implementation makes sense. That said, two > things we could consider doing are:
Thanks for checking. > - Remove the guard pages. I'd rather keep them in though, since > their cost is negligible in most scenarios. If we really wanted > to recover this performance, we could just enable the guards > (by calling mprotect) only under TCG_DEBUG. > > - Change tcg_n_regions() to assign larger regions. I am not convinced > of this, since at most we'd gain 3% in performance, but we might > end up wasting more space (recall that not all vCPUs translate > code at the same rate), or flushing more often (probably with > a perf impact larger than 3%). If we change anything at all, my preference would be to simply remove the guard pages. We have other asserts that pre-date the guard pages that should prevent us from tromping on the next region -- the program should have crashed with SIGABRT before hitting the guard page -- so I'm not especially worried about dropping them. And while it doesn't apply to x86-64, other hosts have even huger huge pages, so IMO it does make sense to prefer a contiguous region when talking about such a large allocation. Does anyone else have an opinion here? r~
