This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Speaking on malloc internals at FOSS.in
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 26 Nov 2012 12:47:26 -0500
- Subject: Re: Speaking on malloc internals at FOSS.in
- References: <20121126040618.GD23633@spoyarek.pnq.redhat.com>
On Sun, Nov 25, 2012 at 11:06 PM, Siddhesh Poyarekar
<siddhesh@redhat.com> wrote:
> Hi,
>
> I'm doing a talk on malloc internals at a conference in Bangalore
> called FOSS.in[1]. I have a slide on future plans or concerns, which
> include the following right now:
>
> * A second look at dynamic thresholds since they worsen fragmentation
> for some cases
> * A look at measuring resource usage in the light of multiple arenas
> * Smarter controls on arena creation, like looking at RLIMIT_AS while
> deciding number of arenas.
>
> The above are tentative ideas based on my experience, which is not
> even close to being as extensive as most people on this list. Hence,
> I'd really appreciate feedback on this and also any additional ideas
> that anyone may have. I'll obviously give credit for the ideas on my
> slides.
* Accepted concensus on opensource benchmarks to use for validating
allocator changes.
* Stable API that allows interaction with allocator running in an application.
- Usable by a debugger, audit library etc.
* Application hook to control arena creation.
- Can use allocator API and application specific information to make
decisions.
* Systemtap probes
- What do we measure? What additional probes do we need?
That's just off the top of my head... hope it helps.
Cheers,
Carlos.