From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <ad616ea212ba4a0741b9343627cd4135@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 21 May 2009 14:04:13 -0400
To: 9fans@9fans.net
In-Reply-To: <dd6fe68a0905211019p3c45859cm457c70dc3828198c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] aux/acidleak pool pathology
Topicbox-Message-UUID: fc174808-ead4-11e9-9d60-3106f5b1d025

> part is requiring the array to be contiguous in the
> first place, but you can't qsort a linked list.

i've sidestepped this problem a few times by building a
linked list and later building an array to sort.  then, if
necessary, relinking the list.  the big allocation is then
done only once.

even after changing to a power-of-two allocation and starting
with 8k items, aux/acidleak still takes 400mb on a 40mb proc
with only 155278 bytes actually allocated (in the target process).

is the a chance that pool is not packing the small
allocations together well?

> if upas/fs is allocating arbitrarily large buffers,
> then its allocation behavior is broken too.

there are a fixed number of large buffers.  up to 15 messages
and mdir uses dirreadall so it can qsort.  the qsort is easy enough
to eliminate, but it's more difficult to bound message buffers.

- erik