This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: fopen from within a pthread
- From: Martin Beynon <mebeyn at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, libc-help at sourceware dot org
- Date: Mon, 4 Jun 2018 17:13:38 +0100
- Subject: Re: fopen from within a pthread
- References: <CADpW=+3ve0oLtby3gneBdiQekjUnqZ66yvhkPUV-LSD9F=dg-g@mail.gmail.com> <CALoOobPHVFYCGpoTmftYMYHvRe=7QTrz_MBY-QwJ04tTMDX4uQ@mail.gmail.com> <36777c73-b695-0438-a916-86caae518128@redhat.com>
Thanks Carlos (and Paul),
I am aware of this...what I wasn't aware of was thread specific arenas.
However that said and understood...it does generate a couple of questions
in my mind:
1) Why doesn't the main program [thread] allocate a 64MB arena? In that
little test program I posted the heap is only 132KB; which leaves me to
wonder why can't the same approach be used for child threads? If I reduce
the MALLOC_ARENA_MAX to 1, the [virtual] memory consumption is the same for
both tests (fopen in thread or in main)...
2) Why can't the initial / default [thread-specific] arena size be changed?
Cheers,
Martin
On 4 June 2018 at 15:38, Carlos O'Donell <carlos@redhat.com> wrote:
> On 06/02/2018 06:48 PM, Paul Pluzhnikov via libc-help wrote:
> > On Sat, Jun 2, 2018 at 3:31 PM Martin Beynon <mebeyn@gmail.com> wrote:
> >>
> >> Is this erroneous behaviour, or can this be explained in some way?
> >
> >
> > There is nothing erroneous about it.
> >
> > What you are observing is the creation of thread-specific arena, from
> > which malloc will return memory to the new thread.
> >
> > GLIBC uses thread-specific arenas to avoid having to lock malloc
> > internal structures when multiple threads allocate and free memory.
> > Additional info can be found here:
> > https://sourceware.org/glibc/wiki/MallocInternals
>
> Also note that VM size is not the same as RSS.
>
> The new thread arena, usually ~64MiB in size on 64-bit, is only taking
> up VM space, but not consuming any real memory (RSS).
>
> Therefore this is just an accounting procedure. Real memory will only
> be used as you dirty the pages.
>
> Cheers,
> Carlos.
>
>