From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2778 invoked by alias); 3 May 2017 03:33:28 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 2765 invoked by uid 89); 3 May 2017 03:33:27 -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,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-languages-length:1554, Wednesday, wednesday, rare X-HELO: homiemail-a80.g.dreamhost.com Subject: Re: [patch/21411] tweak realloc/MREMAP comment To: libc-alpha@sourceware.org References: From: Siddhesh Poyarekar Message-ID: <0f00ed8c-5d8f-07f2-9f67-b1fd50c47e3d@gotplt.org> Date: Wed, 03 May 2017 03:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00051.txt.bz2 On Wednesday 03 May 2017 02:00 AM, DJ Delorie wrote: > 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/) Yes. Siddhesh > > 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. >