From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 583D13858413 for ; Thu, 25 Nov 2021 00:52:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 583D13858413 Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1AON3h5d031418; Thu, 25 Nov 2021 00:52:19 GMT Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by mx0b-00069f02.pphosted.com with ESMTP id 3chmfn436b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Nov 2021 00:52:19 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 1AP0ku7I131437; Thu, 25 Nov 2021 00:52:13 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2102.outbound.protection.outlook.com [104.47.55.102]) by userp3030.oracle.com with ESMTP id 3cep52mexu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Nov 2021 00:52:12 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TOYBMyF+GDQ4YQrSdmikdaTI5eTuvkFz75Pl60H/ioBZCwMpVU2Sk8+z1E9O0rhS3MDCjxPehVuItrBSNeQQb6vmQl3HR9PI2MACgAZimPQpl7I75U6F140dfgvhl0/8AW32+ZmIKNhJNnv54aC3i9ovZdqUU+JAoLQumH+P4R1jjbzu9kRQs7GkrgMiaNX2Z/BrY4481SKBUhqdnSzhIVb8gGybHrMHXYyzinwuO55tryAXUESqJuzhzXmZdgdBtXjDeUX2bJxdytBP1t5C4RblSkLvsF4tWXO4GRAc1F0nx2yf6j/Tzfdu1QFOWgSvSZ9C6excaT0BLn+zG7HIwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AoeXkA4/DB55e4B0YxmKVf2bK/RXV8VI2sixMXgAdMU=; b=LaFoKRcRl8XwzgB/87PO9Q9T3FoKdCy2aJJDSunvFNfGtkB1cXuvXlqqFYw5dXh5+TsjD+Z+HEKNt9J24DToi6703YPlyoPOFnUkHtm2lY46VNIKre6sLfBkG96e1cluqVOBoUNMndSzBzKya9vsBaQ3aO8j5YfHnhjjH88kQ/RLGBamphA0f4YIdV0jUfQjJh7eeGzd18iiJXPdv+3Azhx01WN8i5K/cwrktjEh5T09tZPMCpbCpg0J2PpgZn9gODJRFtrJ3yK6cNb+0JyX4lgjzFcfNJUMGBCK8nQQFfzjv6cLci/g+rYyDWssvOPB7urhQH7DRKL4GviJ3ovpiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from BYAPR10MB3208.namprd10.prod.outlook.com (2603:10b6:a03:159::10) by SJ0PR10MB4685.namprd10.prod.outlook.com (2603:10b6:a03:2df::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Thu, 25 Nov 2021 00:52:10 +0000 Received: from BYAPR10MB3208.namprd10.prod.outlook.com ([fe80::cdd5:fa7c:b36d:dfd2]) by BYAPR10MB3208.namprd10.prod.outlook.com ([fe80::cdd5:fa7c:b36d:dfd2%2]) with mapi id 15.20.4713.027; Thu, 25 Nov 2021 00:52:10 +0000 Message-ID: <4a54b7de-bf41-6550-0e9a-e7a17e9c3b8c@oracle.com> Date: Wed, 24 Nov 2021 18:52:06 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH v2] Remove upper limit on tunable MALLOC_MMAP_THRESHOLD Content-Language: en-US To: DJ Delorie Cc: libc-alpha@sourceware.org References: From: Patrick McGehearty In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SA9PR03CA0006.namprd03.prod.outlook.com (2603:10b6:806:20::11) To BYAPR10MB3208.namprd10.prod.outlook.com (2603:10b6:a03:159::10) MIME-Version: 1.0 Received: from [10.154.108.223] (138.3.200.31) by SA9PR03CA0006.namprd03.prod.outlook.com (2603:10b6:806:20::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.20 via Frontend Transport; Thu, 25 Nov 2021 00:52:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5d143a4d-4efc-4da4-11ae-08d9afadd010 X-MS-TrafficTypeDiagnostic: SJ0PR10MB4685: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: L490F8nJXDR+lbt7tdoAo4IiXmKEwThKnlVTWlkuF/ZKQ53AdnNaegi2cRCWOKxMhbVI45BKAZu842OnDXGPPH1gX4/jw07Xiwwe+C/zBaQrjtbeCiCOrnFkqBQ39dLYel/YNVCBLIheH82Z5tsFYKMddFHQ6m8MmU/odRKm4DWNw/sner4/V0VrNpRl5FHV2sX1MZKFh5PEZ+puJRtorp6KOHOEZF4fDrKt23f53lsuts9bG5X0B7mCvvEHUbo1ZB0/5aGtju2dk/r/OkyR8RUeX0iaJaK7GMqsq/w86an+e/h/wOKWw2pvC4TY0o9UKLBzwZvXvwpJ/yrqM3INYGx6gOSTAzVDusB6qZOMxSeCOYzBwP9ywanXlBzApzYWLg3C65zXTRcouy0VjXtMNMiQ29yYMINKE7JsFibQyCw65OGDtYCBdANncvWCjYdBvlfXkTZFw9c0Ukvlmcsd4RiCyEi0WkPHjT9yxF9dxh3gnK5ZC8fQQVfqInRNCShr7j36yVMkoJAH5VVWC7DwIzDtADcqASH3waRTvOXjGxpeuBAkVLMOw4TUJPs0QT467bqP5hxNCgsu7grRdZlTLAdJHJkgqOpU3Pk1tGBd4Ds60lbw0g9wibeQvqj48Xf8E9+nftXEJru4tcHgZQP5ATgVALjr0hJtr+gO14oMCQVkCSwA8U8WHV4fdN2b9AQ9aY02OBduwk7Yp9mvUDZu+AIAde+u1SCrSPPX5UjwHABndopONF95ZEAk8w2p+Xu/Gf0c+FEsOy1FImBFssrHYA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR10MB3208.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(31696002)(83380400001)(38100700002)(5660300002)(186003)(8676002)(956004)(52116002)(66476007)(6486002)(66556008)(66946007)(316002)(2906002)(38350700002)(36756003)(6666004)(2616005)(4326008)(508600001)(6916009)(53546011)(26005)(31686004)(86362001)(8936002)(16576012)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aSsxS2lKWTduck1qamJPYzFPTFRUTDhDYWxXSlRMWWFJSWFwTkV2MnJNbVFE?= =?utf-8?B?NFNGQmdZZXBuZW9Vd0VBSEZwdTBxcFh2UEZ3N2FoWnZ3UDNUKzVhSXRVSTRB?= =?utf-8?B?dTIyQiszTmlzcGd4MkNraE1DVjF6UXFKQzJiL1puc3c5OHM1ZFNPOU9Wbzho?= =?utf-8?B?ZmMwaG9xTSttd0pSVGxDTlBZT3dnSzVuSkVBcGlla0VzeHJUWC9TMW54Ukpt?= =?utf-8?B?YXFuLzNNaHlVOTA2clZzSHBSeVZTeGYxREpyS3VOZ05mUHZmbDAzL0RIZTNy?= =?utf-8?B?TlVSMVExKytMRElPQm5yTUhmajdrajFnRytxcEgzNk9Za0c1aEExREhieERT?= =?utf-8?B?eWYzZmovSEpIeXptOU55ZTd6cE5yQU0rWWlzUmlCaWlEbHBSMDc5emcrS01V?= =?utf-8?B?TWJ3K2JaUTVrbHBNNkkwNTllT1Z3ZUQ4UzVIck5ITWJWYzVGUjhqNFBjcVF3?= =?utf-8?B?VHFzQ1FvSkxzLzN0ZDFLK0ZZSDZWNjNXZkttSkFIbzBqQ1QzUmgxTWxEU1BY?= =?utf-8?B?OGZDM1JXYzRQVGZNZlF5d2pSVkJnRENjMDJJb0JTa3RIdXdFYTZHeGNvZW9v?= =?utf-8?B?V25kdVorUCsxdXFMMGVzcHJZV2ZUNDZ6NHdYR0szM1V3dm1OcTNESWk2Uk1n?= =?utf-8?B?Wjd4Ums2TzR0RStxZFZhakxiZDFvamJHUi8zeGZaMWNpWVE1QlpER1RWZUlG?= =?utf-8?B?MmtPYVJQYUU1dzVKYW9wVmNaNlFMTjROSUQzOTI4NTFvQmYyRXlxRG1LTDBx?= =?utf-8?B?UHhPc0o2SVJpNExEcHhyV211ZENSUzNmZU5rbTcxOWF1WVNRT3hrU2hERits?= =?utf-8?B?TE5tSGJ1akVDQUd4emRBT0p5UnN0cWNSOFMxeU9rMk1wd2lyZDhyc0JCdmtQ?= =?utf-8?B?MEZIY29iT3NScExlWkZ3TEZGeGZPdlBQNm5TbFdmNnd4emM2bnhVbzZMZGtB?= =?utf-8?B?dmFBdStpc2YybTNRSzRJUWZ0eWRHVW1waG5ZSXVRc2VtZnpGTDlXTXlGNW5h?= =?utf-8?B?WlI3b2lwbCtPMTZqUWc3bGtoOWI5UDZQSVFMODYrS3ZYNEMzWUtNM3RYaGMr?= =?utf-8?B?dk1oUWFMRFAwZlhoN3lPdWZhUXhsUkQ1amliTG9FaG1VTElWbG1mN1BFckRE?= =?utf-8?B?alBURTE3NjZjc2JkaWxTV2pHbjVXendkaTNhUnkzVXhKLzRmWWNTckk4VWZS?= =?utf-8?B?elpldHN1WUNyanUwUHdqWXNpTHBGMmxoVDFUSDRSS1ArNXorV1NWNzkzUytG?= =?utf-8?B?MHNGaE9pUi8rMGtFVGI0aDIySnRBSVJOYjdTcSt1WStsVE5hOWRFejFqSW00?= =?utf-8?B?Q1JDR1Y5RUptVFd2UllXT2RJSi9mSTcrY0gxbGdTOTE3d2I4NU1tb2dpZTJs?= =?utf-8?B?UFhscFZNYzl5T1hxVzFjclRNR1laVTRNYU1TSVRjNW54cmZmQ05NOTl6VTJV?= =?utf-8?B?R2ptbSs5czRYaEhYYmdPUHAzM05La25xeXhBcEw0K3A1TC9VaUlkNHl2Ymw2?= =?utf-8?B?b28xb0xPeVBLbG93RGE5UXVtcThGTFlJTmpaK3pZNGlnS3lYWU1WcWVKbURZ?= =?utf-8?B?SWhsNFhvcHJ1Yzg3c3BjZnlzUml4YzJpQUhTN0NHNHFLT291aWMrMGZONGVn?= =?utf-8?B?OHNoVmloditHUnlGK1JJUW11ZjB5V1Z5d3ptUW9zWTNNV3VXWlAwLy8zRW8z?= =?utf-8?B?U3ViTklVdlMySkc5SkthZENDSnVuWjk2WXFSQlZhWFlmdEx6UHlIUWVEaFRI?= =?utf-8?B?SHBKTU16K1R4Z3dCTTRXenB4KzRkQkQ4cWo0eGRtNFNrSUsyRHZKSEhiN1Ar?= =?utf-8?B?Y3FuTXlYUjRsUDBXQ2Rmd1JHZmwzMEFydUZ1bXRPdWVXaHIwbitYWmh4eFNP?= =?utf-8?B?VXhBaUo2SGJ1UHpzTFpySndEZHpQbXV0bndCNFMxdE0xTjZEeTFYZFhlck1k?= =?utf-8?B?TWZNL1VObHJJTDAzU1U1TlVsVldzMC9TNWx6TXlEaE13bldaWktHZnN4bkdP?= =?utf-8?B?YzhsVXZ5bzBEZ3g0NUI0TTNBU3dqT3haSlZCRko5eG5VelM2dUROOEV1aDlJ?= =?utf-8?B?VFFTQ0c5b2w0RllJZGRkdWFrYW9YVjNUU2t5MTkvOEVMSWVkL3JGUkV2cmwy?= =?utf-8?B?QXhWYmYyZjJsQXlmMDRuQnhpZjhHRmxJUEg2S0pYdEZjMGNzYytqczNDNUZp?= =?utf-8?B?cUhyTzhxdmJ5TmZMY1d6UlcrMFF6ZU4rMGlNRlNtR01PZGIxbkdMWFFWOE5B?= =?utf-8?B?NDhETjVTdnE5ci9FeW9xRVJQUVN3PT0=?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d143a4d-4efc-4da4-11ae-08d9afadd010 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3208.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2021 00:52:10.7321 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zeOOPox7rUEGoel07YHL7D+wXmda8RJBOukzgwHMH/UrdI07lljPiL3HMiZ9myKwB974BlA9pCeUUSRi0c+AVTeHZauhAzZSoDX6qxbrgtI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4685 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10178 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111250001 X-Proofpoint-ORIG-GUID: iFPRTeV8OtwV2D3bvxwCpU8hzkYxCakM X-Proofpoint-GUID: iFPRTeV8OtwV2D3bvxwCpU8hzkYxCakM X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 00:52:24 -0000 After studying the main malloc code paths, I believe I can summarize the malloc behavior when the request is below MALLOC_MMAP_THRESHOLD and above HEAP_MAX  as follows (omitting much code for failure paths, etc): malloc trys to find an arena with enough memory. If success, allow, return. If no arena is usable, call sysmalloc to get more system memory. [We are concerned with large allocations where no arena has enough memory, so we continue with:] sysmalloc does the following: If there is no usable arena or (the request exceeds mmap threshold and we have not hit the mmap section limit), then we "try_mmap". [But we are asking about the case where we exceed HEAP_MAX_SIZE but not mmap_threshold, meaning we will bypass try_mmap here.] If we don't try_mmap and sysmalloc was called without an arena, then we return 0 (i.e. fail). If the above cases do not apply, then we have two branches, one for a non-main arena and one for the main arena. [I believe the following is the case the reviewer was concerned about.] If the arena is not the main arena (I'm guessing this case only applies to multi-threads apps), then we either try to grow_heap (but not this time because our request is too large) or we call new_heap. The new_heap call will fail because our request exceeds HEAP_MAX_SIZE. At this point, if we have not yet tried mmap, we jump back to try_mmap. The try_mmap: label bypasses the test for mmap_threshold as the label is below the if clause. As far as I can tell from reading the code, following this path, the mmap call succeeds and a single chunk is allocated to fulfill the request. [This case is where we agree that all is as expected.] If the arena is the main arena (i.e. single threaded app), then we call MORECORE (usually sbrk) to extend the arena region as desired. - patrick On 11/9/2021 6:36 PM, DJ Delorie wrote: > Patrick McGehearty writes: >> If a chunk smaller than the mmap_threshold is requested, >> then MORECORE [typically sbrk()] is called and HEAP_MAX >> is not considered by the malloc code.  Heaps are only used >> for mmap()ed allocations, not sbrk()'ed allocations, >> so far as I can tell in reading the code. > There are two types of arenas: the sbrk-based arena (limited in size by > ulimit), and zero or more mmap-based arenas (limited by HEAP_MAX). The > sbrk-based one is used when the program is single threaded; the > mmap-based ones are used when the program is multi-threaded. Your > original email made it sound like you were concerned with the > multi-threaded case, where the mmap-based heaps are used. > > In either case, a malloc() request may be satisfied by pulling a free > chunk out of either type of arena (possibly growing the arena if needed > and possible), or by calling mmap() directly to satisfy that one > request. > > I would think mmap_threshold should still apply if you're using the > mmap'd heaps, so you can reserve the heaps for smaller chunks, but that > is meaningless if mmap_threshold is larger than the heap size. I could > not find an obvious place in the code where mmap_threshold is used to > bypass the mmap'd heaps, though. > > So while I have no problems with allowing larger mmap_threshold settings > for the sbrk-based arena, I still wonder what happens to requests that > go through an mmap-based arena that are larger than HEAP_MAX but still > under the mmap_threshold. > > Of course, I've spent more time typing this response than it would take > to write a test program and see what happens ;-) > >> It might be desirable to also allow HEAP_MAX to be set by >> the user before the first call to malloc, but I see that >> as a separate task. > Our current implementation requires that the heap size be a compile-time > constant, but... yeah. >