Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760037AbXF0MdT (ORCPT ); Wed, 27 Jun 2007 08:33:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756650AbXF0MdM (ORCPT ); Wed, 27 Jun 2007 08:33:12 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]:2775 "EHLO extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756531AbXF0MdL (ORCPT ); Wed, 27 Jun 2007 08:33:11 -0400 Date: Wed, 27 Jun 2007 13:32:35 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@blonde.wat.veritas.com To: Ulrich Drepper cc: Davide Libenzi , Linux Kernel Mailing List Subject: Re: [patch 2/3] MAP_NOZERO - implement sys_brk2() In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAA2luYm94AGRhdmlkZWxAeG1haWxzZXJ2ZXIub3JnAGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcAZHJlcHBlckBnbWFpbC5jb20A X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1434 Lines: 31 On Tue, 26 Jun 2007, Ulrich Drepper wrote: > On 6/26/07, Davide Libenzi wrote: > > > OTOH glibc could implement __morecore using mmap(MAP_NOZERO), and hence > > brk2() would not be needed, no? > > No. mmap calls create individual VMAs which gets expensive. There > are also some hardware drivers which get more expensive the more VMAs > there are. I want to go away as much as possible from mmap for > malloc. Not so: if an mmap can be done by extending either adjacent vma (prot and flags and file and offset all match up), that's what's done and no separate vma is created. (And adjacent vmas get merged when mprotect removes the difference in protection.) I don't think there's any such reason to prefer brk to mmap. But you may have encountered something which we in the kernel are thinking of as an insignificant corner case, which is actually breaking things up badly in practice (I recall the kernel's internal VM_ACCOUNT flag, relating to non-overcommit accounting, which might get turned on at any time, sometimes preventing a vma merge you'd otherwise expect). Please let me know if you've a test case which shows more vmas than expected. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/