On Sat, Dec 7, 2013 at 4:09 AM, Phong Vo <[email protected]> wrote: > On Fri, Dec 6, 2013 at 10:18 AM, Glenn Fowler <[email protected]> > wrote: >> On Thu, Dec 5, 2013 at 6:41 PM, Roland Mainz <[email protected]> >> wrote: >>> On Wed, Dec 4, 2013 at 3:02 PM, Glenn Fowler <[email protected]> >>> wrote: >>> > On Sun, Dec 1, 2013 at 4:58 PM, Lionel Cons <[email protected]> >>> > wrote: [snip] >>> Just to make it clear: Allocating a 1MB chunk of memory via >>> |mmap(MAP_ANON)| and a 128MB chunk of memory via |mmap(MAP_ANON)| has >>> *no* (visible) difference in performance until we touch the pages via >>> either read/execute or write accesses. >>> Currently the libast allocator code writes zeros into the whole chunk >>> of memory obtained via |mmap(MAP_ANON)| which pretty much ruins >>> performance because *all* pages are created physically instead of just >>> being some memory marked as "reserved". If libast would stop writing >>> into memory chunks directly after the |mmap(MAP_ANON)| we could easily >>> bump the allocation size up to 32MB or better without any performance >>> penalty... > > Vmalloc disciplines do not zero out memory. The only explicit zeroing of > memory occurs in the call vmresize() and only with the flag VM_RSZERO or in > the malloc-compatible calloc() call.
Erm... see http://lists.research.att.com/pipermail/ast-developers/2013q4/003770.html ... there is one in src/lib/libast/vmalloc/vmopen.c ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-users mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-users
