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: 757810 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wHXxG6MMQz9s7f for ; Wed, 3 May 2017 06:30:58 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="oDSZ5nKx"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:message-id:from:to:subject; q=dns; s= default; b=pvvPPhLCkx3pFvWgzauN4MurN539uOLqfkZfj06chSoCjX8cQt3LK cu+plMAYGOtw4pS3fwrw+OZyDrSHrHfXHn4zHCGW8bhZyllZoMWBU2RXgsc9Ep9D xeUiNyWTZusvjyzItb4qqXr3/zLiwako6xiMrY2WjSjmIEfuLNWRxs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:message-id:from:to:subject; s=default; bh=KSwQOuLFDDJSlPewM3WH4C6L/Q0=; b=oDSZ5nKxYGlRziABNvR4xiT5K120 E0NyDWQJeebIwvxKayziIFJQ5xlqIXHl2GWDwKwQsyNGDrN057cl6ugMnSM5G80j c2Rs6bRPYUGTCeGMMwzYr8ADD2qiZBbaxrkP/Nia16XOrKJhgNMWmiRit7K3h+M5 +gquw5N0hxxa5WM= 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.