From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5268 invoked from network); 6 Jan 2022 22:00:31 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Jan 2022 22:00:31 -0000 Received: (qmail 28356 invoked by uid 550); 6 Jan 2022 22:00:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28313 invoked from network); 6 Jan 2022 22:00:27 -0000 Date: Thu, 6 Jan 2022 17:00:14 -0500 From: Rich Felker To: Colin Cross Cc: musl@lists.openwall.com Message-ID: <20220106220014.GI7074@brightrain.aerifal.cx> References: <20220106203709.1525763-1-ccross@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220106203709.1525763-1-ccross@google.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] Add mallinfo2 and mallinfo On Thu, Jan 06, 2022 at 12:37:09PM -0800, Colin Cross wrote: > glibc introduced mallinfo2 [1], which solves some of the arguments [2] > against including mallinfo in musl by expanding the width of the > returned counters from int to size_t. > > This patch implements mallinfo2 without requiring any additional > metadata. It iterates through the meta_areas and metas in order > to count mmap, large and small allocations, and produces ordblks, > hblks, hblkhd, uordblks and fordblks values. > > Once mallinfo2 exists, it is trivial to implement mallinfo that caps > the mallinfo2 outputs such that they fit in the int fields returned > by mallinfo. > > [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=e3960d1c57e57f33e0e846d615788f4ede73b945 > [2] https://www.openwall.com/lists/musl/2018/01/17/2 Historically, mallinfo was omitted intentionally in musl partly because of the wrong-types issue (fixed by mallinfo2), but also partly because the set of data items returned is built around certain assumptions about the malloc implementation that aren't necessarily valid, especially for our allocators. This could be revisited, but I'm not sure we'll find good justification to add it. > --- > > The motivation for this patch is an attempt to use musl instead of glibc > to build host tools used when building the Android platform and the > tools that are distributed to app developers as part of the Android SDK. > mallinfo is used in a variety of third-party code built as part of > building Android, and tests and benchmarks in the Android tree. > > The implementation has been lightly tested with bionic's malloc.mallinfo > and malloc.mallinfo2 tests, which verify that a variety of different > allocation sizes result in an increase of the uordblks value by at > least the usable size of the returned allocation. > > I can keep this as a local patch in Android if it is still not acceptable > for musl. Is there a reason not to just #ifdef HAVE_MALLINFO it out, or do a dummy implementation, or one that makes up semi-reasonable numbers purely based on /proc/self/maps without poking at malloc internals? > dynamic.list | 1 + > include/malloc.h | 30 ++++++++++++++ > src/malloc/mallocng/mallinfo.c | 73 ++++++++++++++++++++++++++++++++++ > 3 files changed, 104 insertions(+) > create mode 100644 src/malloc/mallocng/mallinfo.c > > diff --git a/dynamic.list b/dynamic.list > index ee0d363b..84d13c53 100644 > --- a/dynamic.list > +++ b/dynamic.list > @@ -14,6 +14,7 @@ memalign; > posix_memalign; > aligned_alloc; > malloc_usable_size; > +mallinfo; > > timezone; > daylight; > diff --git a/include/malloc.h b/include/malloc.h > index 35f8b19c..98ba0100 100644 > --- a/include/malloc.h > +++ b/include/malloc.h > @@ -18,6 +18,36 @@ void *memalign(size_t, size_t); > > size_t malloc_usable_size(void *); > > +struct mallinfo { > + int arena; > + int ordblks; > + int smblks; > + int hblks; > + int hblkhd; > + int usmblks; > + int fsmblks; > + int uordblks; > + int fordblks; > + int keepcost; > +}; > + > +struct mallinfo mallinfo(void); > + > +struct mallinfo2 { > + size_t arena; > + size_t ordblks; > + size_t smblks; > + size_t hblks; > + size_t hblkhd; > + size_t usmblks; > + size_t fsmblks; > + size_t uordblks; > + size_t fordblks; > + size_t keepcost; > +}; > + > +struct mallinfo2 mallinfo2(void); > + > #ifdef __cplusplus > } > #endif Small issue, but if this is to be upstreamed it should use indentation correctly (tabs to indent, spaces to align). > diff --git a/src/malloc/mallocng/mallinfo.c b/src/malloc/mallocng/mallinfo.c > new file mode 100644 > index 00000000..c60840b1 > --- /dev/null > +++ b/src/malloc/mallocng/mallinfo.c > @@ -0,0 +1,73 @@ > +#include > +#include > +#include > + > +#include "glue.h" > +#include "meta.h" > + > +static void accumulate_meta(struct mallinfo2 *mi, struct meta *g) { > + int sc = g->sizeclass; > + if (sc >= 48) { > + // Large mmap allocation > + mi->hblks++; > + mi->uordblks += g->maplen*4096; > + mi->hblkhd += g->maplen*4096; > + } else { > + if (g->freeable && !g->maplen) { > + // Small size slots are embedded in a larger slot, avoid double counting > + // by subtracing the size of the larger slot from the total used memory. > + struct meta* outer_g = get_meta((void*)g->mem); > + int outer_sc = outer_g->sizeclass; > + int outer_sz = size_classes[outer_sc]*UNIT; > + mi->uordblks -= outer_sz; > + } > + int sz = size_classes[sc]*UNIT; > + int mask = g->avail_mask | g->freed_mask; > + int nr_unused = __builtin_popcount(mask); > + mi->ordblks += nr_unused; > + mi->uordblks += sz*(g->last_idx+1-nr_unused); > + mi->fordblks += sz*nr_unused; > + } > +} For upstreaming, __builtin_popcount wouldn't be usable. But aside from that, the approach here looks roughly correct. I don't see any correction for the case where a g->last_idx==1 and sc<48, in which case it's possible that map_len is less than the length for the size class. These should probably be treated like "individually mmapped" allocations. This is one place where trying to fit the mallinfo data model with an allocator that doesn't match its assumptions is something of a hack. > + > +static void accumulate_meta_area(struct mallinfo2 *mi, struct meta_area *ma) { > + for (int i=0; inslots; i++) { > + if (ma->slots[i].mem) { > + accumulate_meta(mi, &ma->slots[i]); > + } > + } > +} > + > +struct mallinfo2 mallinfo2() { > + struct mallinfo2 mi = {0}; > + > + rdlock(); > + struct meta_area *ma = ctx.meta_area_head; > + while (ma) { > + accumulate_meta_area(&mi, ma); > + ma = ma->next; > + } > + unlock(); > + > + return mi; > +} > + > +#define cap(x) ((x > INT_MAX) ? INT_MAX : x) > + > +struct mallinfo mallinfo() { > + struct mallinfo mi = {0}; > + struct mallinfo2 mi2 = mallinfo2(); > + > + mi.arena = cap(mi2.arena); > + mi.ordblks = cap(mi2.ordblks); > + mi.smblks = cap(mi2.smblks); > + mi.hblks = cap(mi2.hblks); > + mi.hblkhd = cap(mi2.hblkhd); > + mi.usmblks = cap(mi2.usmblks); > + mi.fsmblks = cap(mi2.fsmblks); > + mi.uordblks = cap(mi2.uordblks); > + mi.fordblks = cap(mi2.fordblks); > + mi.keepcost = cap(mi2.keepcost); > + > + return mi; > +} > -- > 2.34.1.448.ga2b2bfdf31-goog If the API is added upstream, it really should be provided by both mallocng and oldmalloc, with the legacy mallinfo (int) wrapper, if any, in src/malloc rather than src/malloc/mallocng. Available functions should not differ based on --with-malloc choice. Rich