I don't know how you are measuring excessive
with the alpha just posted there are no timing or memory diffs on linux for
segsizes 64Ki 4Ki 8Ki 64Mi
add usage to VMALLOC_OPTIONS to get a summary of total region usage in the
last line
all the segsizes show ~250Mi total usage

$ time VMALLOC_OPTIONS=segsize=64Ki $SHELL ./t01

real    0m14.61s
user    0m14.45s
sys     0m0.14s
$ time VMALLOC_OPTIONS=segsize=4Mi $SHELL ./t01

real    0m14.51s
user    0m14.36s
sys     0m0.14s
$ time VMALLOC_OPTIONS=segsize=8Mi $SHELL ./t01

real    0m14.68s
user    0m14.48s
sys     0m0.19s
$ time VMALLOC_OPTIONS=segsize=64Mi $SHELL ./t01

real    0m14.49s
user    0m14.33s
sys     0m0.14s
$ time VMALLOC_OPTIONS=segsize=64Mi,usage $SHELL ./t01
vmalloc: 0x25c2064e6000 67108864 init
vmalloc: 0x25c2064e6000 67108864 init
vmalloc: 0x25c2064e6000 67108864 region 0x007db200 size=268435456 segs=1
packs=1 busy=58% cache=115424/1801

real    0m15.03s
user    0m14.61s
sys     0m0.40s



On Tue, Dec 10, 2013 at 4:16 AM, Lionel Cons <lionelcons1...@gmail.com>wrote:

> On 6 December 2013 16:18, Glenn Fowler <glenn.s.fow...@gmail.com> wrote:
> > On Thu, Dec 5, 2013 at 6:41 PM, Roland Mainz <roland.ma...@nrubsig.org>
> > wrote:
> >> 2. The default block size by the normal |mmap(MAP_ANON)| allocator is
> >> 1MB. This is IMHO far to small because there is IMO not enough space
> >> for the coalescing algorithm to operate and a *lot* of fragmentation
> >> occurs.
> >> IMHO a _minimum_ page size of 4MB should be picked (as a side-effect
> >> the shell would get 4MB or 2MB largepages on platforms like Solaris
> >> automagically).
> >
> >
> > default block size upped to 4Mi and pagesize=<n>[KMGP][i] can ovveride in
> > VMALLOC_OPTIONS for testing
>
> A default block size of 4Mi is not sufficient on linux/x86-64 and
> Solaris/x86-64 to prevent the excessive memory consumption. I've
> played with script to create a graph to see where the excesses stop
> and the turning point is at 8.4Mi.
>
> So, if the default block size is bumped it should be bumped to at least
> 8Mi.
>
> Lionel
>
_______________________________________________
ast-developers mailing list
ast-developers@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers

Reply via email to