From patchwork Tue May 2 20:30:43 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: DJ Delorie X-Patchwork-Id: 20227 Received: (qmail 98912 invoked by alias); 2 May 2017 20:30:45 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 98890 invoked by uid 89); 2 May 2017 20:30:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*r:8.14.7, rare X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6D4EFC059752 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dj@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6D4EFC059752 Date: Tue, 02 May 2017 16:30:43 -0400 Message-Id: From: DJ Delorie To: libc-alpha@sourceware.org Subject: [patch/21411] tweak realloc/MREMAP comment I think this subtle change makes the comment match the existing source better. However, we never actually munmap pages when shrinking mmap'd chunks... in theory, we could just use munmap() even if mremap is unavailable, yes? (and even if we make that change, we would then add a *new* comment documenting that behavior, the old comment still wouldn't be corect). IIRC, we don't try to map-copy-unmap such shrinking chunks because they tend to be very large, and would incur a large cost penalty for a rare case, where the kernel could just swap out the unneeded pages. Patch ok? (it's basically just s/reallocated/grown/) diff --git a/malloc/malloc.c b/malloc/malloc.c index 068ffc1..aa45626 100644 --- a/malloc/malloc.c +++ b/malloc/malloc.c @@ -514,9 +514,9 @@ void* __libc_calloc(size_t, size_t); REALLOC_ZERO_BYTES_FREES is set, realloc with a size argument of zero (re)allocates a minimum-sized chunk. - Large chunks that were internally obtained via mmap will always - be reallocated using malloc-copy-free sequences unless - the system supports MREMAP (currently only linux). + Large chunks that were internally obtained via mmap will always be + grown using malloc-copy-free sequences unless the system supports + MREMAP (currently only linux). The old unix realloc convention of allowing the last-free'd chunk to be used as an argument to realloc is not supported.