public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@sourceware.org>
To: Nicolas Dusart <nicolas@freedelity.be>, libc-alpha@sourceware.org
Cc: Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [PATCH] realloc: Limit chunk reuse to only growing requests [BZ #30579]
Date: Wed, 5 Jul 2023 06:46:06 -0400	[thread overview]
Message-ID: <df3862ca-8ba7-98d8-5a63-2ccb19cf51b0@sourceware.org> (raw)
In-Reply-To: <911272453cd5141dbe1ccbcc1e195296c5573ca0.camel@freedelity.be>

On 2023-07-05 03:08, Nicolas Dusart wrote:
> Siddhesh, if you happen to find an heuristic that is suitable and can
> save reallocations for bigger shrinks, may I suggest to avoid reusing
> an option if the new behavior of this option does not fit exactly in
> the expectation of how it worked earlier ?

FWIW, the original optimization was not for shrinks; the shrinks came in 
as a side-effect and I thought it would be clever to allow shrinking up 
to trim threshold and didn't anticipate the broad impact then.  A number 
of distributions tend to rebase early and I had expected applications 
like redis to stumble over if anything was amiss, which didn't happen. 
I reckon the plasma desktop issue didn't get caught early because the 
proactive rebasers (Fedora, Suse Tumbleweed and Ubuntu) are primarily 
Gnome based.

In any case, this patch limits the optimization to growths only, which 
is far more convenient to reason because it grows into existing unused 
padding.  There's no real benefit to keeping parts of a block around in 
case of a shrinking allocation AFAICT.  This growth-into-padding 
optimization is also useful only because it's a relatively lightweight 
check; if it gets any more complex then it's probably not worth the effort.

Sid

  reply	other threads:[~2023-07-05 10:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-04 18:24 Siddhesh Poyarekar
2023-07-05  7:08 ` Nicolas Dusart
2023-07-05 10:46   ` Siddhesh Poyarekar [this message]
2023-07-05 11:55 ` Aurelien Jarno
2023-07-05 14:37   ` Siddhesh Poyarekar
2023-07-05 18:30     ` Aurelien Jarno

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

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

  git send-email \
    --in-reply-to=df3862ca-8ba7-98d8-5a63-2ccb19cf51b0@sourceware.org \
    --to=siddhesh@sourceware.org \
    --cc=aurelien@aurel32.net \
    --cc=libc-alpha@sourceware.org \
    --cc=nicolas@freedelity.be \
    /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).