unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: libc-alpha@sourceware.org
Subject: status of dj/malloc branch?
Date: Mon, 1 Apr 2024 19:19:25 +0000	[thread overview]
Message-ID: <20240401191925.M515362@dcvr> (raw)

I'm interested in the tracing features described at
https://sourceware.org/glibc/wiki/MallocTracing
to test and validate memory fragmentation avoidance in a long-lived
single-threaded Perl C10K HTTP/IMAP/NNTP/POP3 daemon.

It appears stalled for years, however, and the current glibc
malloc doesn't have the trace + replay features.

I'm currently dogfooding the below patch on an old glibc (Debian
oldstable :x) on my "production" home server.  My theory is the
jemalloc idea of having fewer possible sizes is good for
avoiding fragmentation in long-lived processes.

This is because sizes for string processing are highly
variable and lifetimes are mixed for event-driven C10K servers
where some clients live only for a single request and others for
many.  Clients end up sharing allocations due to caching
and deduplication, so a short-lived client can end up allocating
something that lives a long-time.  Perl does lazy loading
and internal caching+memoization all over the place, too.

The downside is 0-20% waste in initial fits, but I expect it to
get better fits over time...

Not a serious patch against Debian glibc 2.31-13+deb11u8:

diff --git a/malloc/malloc.c b/malloc/malloc.c
index f7cd29bc..6e0b066d 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -3018,6 +3018,31 @@ tcache_thread_shutdown (void)
 
 #endif /* !USE_TCACHE  */
 
+static inline size_t
+size_class_pad (size_t bytes)
+{
+  if (bytes <= MAX_FAST_SIZE || bytes >= DEFAULT_MMAP_THRESHOLD_MAX)
+    return bytes;
+  /*
+   * Use jemalloc-inspired size classes for mid-size allocations to
+   * minimize fragmentation.  This means we pay a 0-20% overhead on
+   * the initial allocations to improve the likelyhood of reuse.
+   */
+  size_t max = sizeof(void *) << 4;
+  size_t nxt;
+
+  do {
+    if (bytes <= max) {
+      size_t sc_bytes = ALIGN_UP (bytes, max >> 3);
+
+      return sc_bytes <= DEFAULT_MMAP_THRESHOLD_MAX ? sc_bytes : bytes;
+    }
+    nxt = max << 1;
+  } while (nxt > max && nxt < DEFAULT_MMAP_THRESHOLD_MAX && (max = nxt));
+
+  return bytes;
+}
+
 void *
 __libc_malloc (size_t bytes)
 {
@@ -3031,6 +3056,7 @@ __libc_malloc (size_t bytes)
     = atomic_forced_read (__malloc_hook);
   if (__builtin_expect (hook != NULL, 0))
     return (*hook)(bytes, RETURN_ADDRESS (0));
+  bytes = size_class_pad (bytes);
 #if USE_TCACHE
   /* int_free also calls request2size, be careful to not pad twice.  */
   size_t tbytes;
@@ -3150,6 +3176,8 @@ __libc_realloc (void *oldmem, size_t bytes)
   if (oldmem == 0)
     return __libc_malloc (bytes);
 
+  bytes = size_class_pad (bytes);
+
   /* chunk corresponding to oldmem */
   const mchunkptr oldp = mem2chunk (oldmem);
   /* its size */
@@ -3391,6 +3419,7 @@ __libc_calloc (size_t n, size_t elem_size)
       return memset (mem, 0, sz);
     }
 
+  sz = size_class_pad (sz);
   MAYBE_INIT_TCACHE ();
 
   if (SINGLE_THREAD_P)

             reply	other threads:[~2024-04-01 19:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-01 19:19 Eric Wong [this message]
2024-04-01 20:59 ` status of dj/malloc branch? DJ Delorie
2024-04-06 22:02   ` Eric Wong
2024-04-08 18:37     ` DJ Delorie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240401191925.M515362@dcvr \
    --to=e@80x24.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).