From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51F53C47258 for ; Sat, 20 Jan 2024 16:39:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89A2B6B006E; Sat, 20 Jan 2024 11:39:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 822AA6B0071; Sat, 20 Jan 2024 11:39:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C3C96B0074; Sat, 20 Jan 2024 11:39:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 58B7F6B006E for ; Sat, 20 Jan 2024 11:39:54 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E743C1607AF for ; Sat, 20 Jan 2024 16:39:53 +0000 (UTC) X-FDA: 81700251066.09.9E04357 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id B720010000D for ; Sat, 20 Jan 2024 16:39:51 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=OIjT7E22; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705768792; a=rsa-sha256; cv=none; b=Kzo5oXnSLJoaQwKYPzz9Y1eCA4+wmEJ7mbpX0vpNzp0I96PF7b6f1NWiuKAA+TBZ2LdlHH 8EGBsr3MnyPAo9emHxudjWmAtsSbAujpUgVIuQc9mhnm2pBHeVN5CM2pjEPibnywHSiMh2 itbnD7nz8S/IldcIabMRrlF1ZrfbxdE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=OIjT7E22; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705768792; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oZ5Lc7Bp8fwMVeENZr2kJiceObz8iC2ZU2MJkAmy2xA=; b=zfy7cgzNV5D2+a9liVH0QjqeseiLar6M/wfxfwilRxgvnMl+mJsAYE+oWlU/sH1P++6VSB zVqpefFFoB4EkxDNx+W5owk5ImydU+Dbc0lHLfECwfgTPcJsIBbxUikHvxtLVHIMJCeCJf TF6C4WerjCuDi2o7B2UOoyXwCS6Izww= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=oZ5Lc7Bp8fwMVeENZr2kJiceObz8iC2ZU2MJkAmy2xA=; b=OIjT7E22+B05YzjxNI0QFcvxRp GmX570zbOpDgMvC+qrGg95qRD1SwgO5axRHIJcZLpqP/M1YcneGVAdOgH6MCMp1d1JLs0uLwzqT6d TaJjWnbHITuBOb6WJ4ucUzWTMQNo6ygD9UEy71mS5Iz2eVeTZxaXsFZJdIqCJorQBnmksA7z2GnAN B8XvwmWy5UTDGVxgiUPtLUGkAUY+82DSDe4rVz+Suof+/fVHHUD2ma6SkxmMVWMuszrgOBwnKJXew /LHFk/Ud4G9mCdZP2WGeei0edj8lqZ9F26i1YNLIUkddOvzRFN1oNEqsTt/aj1fmMJ1GiDrBncFpV A3tAviHA==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rRENk-0000000A8nI-24D5; Sat, 20 Jan 2024 16:39:44 +0000 Date: Sat, 20 Jan 2024 16:39:44 +0000 From: Matthew Wilcox To: Ryan Roberts Cc: Yang Shi , riel@surriel.com, shy828301@gmail.com, cl@linux.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RESEND PATCH] mm: align larger anonymous mappings on THP boundaries Message-ID: References: <20231214223423.1133074-1-yang@os.amperecomputing.com> <1e8f5ac7-54ce-433a-ae53-81522b2320e1@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e8f5ac7-54ce-433a-ae53-81522b2320e1@arm.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B720010000D X-Stat-Signature: 3ushhuzazbu1pi67mjyhftioqqmzpms9 X-HE-Tag: 1705768791-432236 X-HE-Meta: U2FsdGVkX18Jq/NxuO3TdmnlFQPPJd9P0zhQGalKlw7xfmzubBHcRcklGkUD+U6Hbl+e5A3xqCFLcbqF29t/62mxUdUYR+coE6g/Spj5XFrU9kLKifm4VP7AS/jjQQlKOlwOgLwX57w0dLrKMlEnu0EThb5LdTy9EZOyaD9bhLUxPQS3BVeJlmQtTjxQUidzA2VbLRW4PZSN4NsdkGQkkIdvoGERZezwchxc8YWVnq7esj4KyEquwUONUK+iOCPhJFXfDgN88E7xs+uVC86X7LpyiFghEdpDwCz8ehGsDQL8gKqsx8v/m2sZf83x+VFyA3oB4R7yH8C12eRpeuSla/PqW3MXtqLBMezRjWxolJ/aJJtuszkqdp7rA820f0RS95rnJkYE8DYNPlsggII1kY8jUH3z1JE9fqIvpsFdF/rfJe5YZl8u8+kR9b/kxdOtx+pk/olCaB6B6SBkZh8MilRpAj8RT/LCeY2Rzq1KJESF8vSFNsgnc0U1/Vbe4EyrvjYmy8hF834JSmSO+ZNBGVBkSuER7cuGAWrHm+frkQkN4YT1PKrE4Ln0Y9/9oq6Qh6kw9JzRtJ6Sp70Cfyfx4wxHjDJ5kfxGgo9KSlIVSdqqP6ALRrj9pWg2hZg391f2abPCH7F1CrmFu+lDYdjCnOJwmf7X1dJmGo3g303d6d3sTDfb7GiroeQEZsYDIaJ42sFolFjm7BL8gijsr282N+v9qZbDG8igx4P6MHv7T8vRZo15pWlcqgBSVZCGrpxq8bSBFW5NgBfNnDlpdRJSjmQoSrKFozPrQh9X1bgjwdAjMOHo7TOWwnAC+kFqTUcgm3/sx882B6DMMOJHrKwuFLdU4SmT8aLo9utwVuKyxx1VXY0KeurpUWKG4PzEGZEk7SdsrHSqRl7LfG/NwpVh5sQA9hw3fZhaZLOZ7pm7/HDmEN/AGi5FSkl1KUSyZjuICxuyUjLHx3i1ASARpYS dVfHwwH6 aXxraqmz4gszxa1zq+1s7yT59Hx+2grMErjD9LSFr5HjNqC56EvJ/BPKACW/yR/lICe1W1KfaF8l708B0cOgaZR377nd10Tgp49KJQxyQdfo7eiQlBojxBhhNnrgZBtBmhqli6eO/bqiv4Yc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, Jan 20, 2024 at 12:04:27PM +0000, Ryan Roberts wrote: > However, after this patch, each allocation is in its own VMA, and there is a 2M > gap between each VMA. This causes 2 problems: 1) mmap becomes MUCH slower > because there are so many VMAs to check to find a new 1G gap. 2) It fails once > it hits the VMA limit (/proc/sys/vm/max_map_count). Hitting this limit then > causes a subsequent calloc() to fail, which causes the test to fail. > > Looking at the code, I think the problem is that arm64 selects > ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT. But __thp_get_unmapped_area() allocates > len+2M then always aligns to the bottom of the discovered gap. That causes the > 2M hole. As far as I can see, x86 allocates bottom up, so you don't get a hole. As a quick hack, perhaps #ifdef ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT take-the-top-half #else current-take-bottom-half-code #endif ?