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 05894C47DDC for ; Mon, 22 Jan 2024 11:37:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21CE36B007E; Mon, 22 Jan 2024 06:37:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CC0A8D0001; Mon, 22 Jan 2024 06:37:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0940B6B0081; Mon, 22 Jan 2024 06:37:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E9B436B007E for ; Mon, 22 Jan 2024 06:37:10 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BEFA2A1DA8 for ; Mon, 22 Jan 2024 11:37:10 +0000 (UTC) X-FDA: 81706745820.26.ED53188 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf24.hostedemail.com (Postfix) with ESMTP id 80667180003 for ; Mon, 22 Jan 2024 11:37:08 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705923429; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ES9Z66AruKPbVMZNfulwSsDegJgSWj9bPSV44WqHIcs=; b=dTDh9siJvouP8FGd3c5InjAaAW06fMiVjYUSQmbb7YQpMkO3LvAakkfWJjdMi9TOi/7VfK CiAjel3zvqmc1OKv2hSWYSeQ1S4ggPIi/zLSr6J6rJo8WlOD0w816ObLAddHEKvHXUeB5V LHG/6cVI11qYxjsll2uNtTRW1ayre38= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705923429; a=rsa-sha256; cv=none; b=f3j9d4v9yTSzp93sUOCwejvgG8OvVsJzKz4lMS3n2jdYP45pU27/uLjb2aTRavEEYSx3f0 kPrcOWnGWf+7RF+U9bL7/Rk5K2e3wfZmDTsn0Mti5TAAzKXyPtxglnU3oSpQOXt3SVg2Lo +u8V1caWb58armgQZBC5F7/IVF/TFT8= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4166F1FB; Mon, 22 Jan 2024 03:37:53 -0800 (PST) Received: from [10.1.33.151] (XHFQ2J9959.cambridge.arm.com [10.1.33.151]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E09E3F5A1; Mon, 22 Jan 2024 03:37:06 -0800 (PST) Message-ID: Date: Mon, 22 Jan 2024 11:37:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH] mm: align larger anonymous mappings on THP boundaries Content-Language: en-GB To: Matthew Wilcox 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 References: <20231214223423.1133074-1-yang@os.amperecomputing.com> <1e8f5ac7-54ce-433a-ae53-81522b2320e1@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 80667180003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: omexezfyt81mtxf7h7fprpgyejbjb59d X-HE-Tag: 1705923428-13964 X-HE-Meta: U2FsdGVkX1+KKZ/KEcBj6oPlrllDqbXBwSeeEu4gMtf0VNR5Q9Bl3SHRJcndGaD9WQawM+RMEyXNvglvJ+01WZP5G7QplwiVX7r+O7cAggW7UMgpiyMgPj274KYM6d8VAx2K4GRTJd0fwPZJHrvdxhFgRExDZUDXpHlfMata8O9uspz6z0kEzfqxpXKBUrv7D6Fw93a6uh2u+zqpc3Q3ya+2Rm7zNDOQaZD0pyKu6Igef1oaAKp86uOPa/Vq73Vd1YPOkf0iQ+FnzPyNx4tzYf0VVWuZV1WnXqEVjmAQPVz7MIhgm5DOs96wo/RbpdY1rKgNGYSREnboRfthRAS6ZhXYfvu1Yh/OQJQPrMN0vY391uuutejBywhVEyVUOVHihXsOOSeAWIyKWyP4Rj9nYsWoluMr6mj/QWDgS9tGd2k7JLKLJl6wm6PUIhEjd4zrnRXYLgOdZm1yRC+4NgYvGQUgEogpI6uFFdATwf0pM7U6rg9tP3gBit7AmfuTmTEDGksvvGr7QrlXmqzxxK7wc+GKXigO8PsUcgoB6en/FhfZR3wsQurczOtakkwzROgT8dwPJCEe75wf6UI/GYaX+ayU27gYO1xvlWuxeu96LTn9J4AbQwiwkxuTcgg//oeIH10X/IwQAHCT0J4cN1VaLQ3F4JF1hb5oNCefEMoSDjAfnsotRs2D7as424NQjR0x2bRKbNfseV8ucx7e6iWR4b0DJZEEB9V/Ijv5t9hT/vCH8f0Nc7NWbp3Brlbq+79993wGO2TRUD5bkQgl/3hg/nNosdHq/On5Zc9tms5d+O8rfVE89ByfX7WNk64BwUkrGn0Wlc5wRStcfLYI2S1gbe+ZhkJzivvMmfWkgKd9T/CHiqmWaW1GrzNmvYc0NZ6zX5o2HJ4ivJ7IMpbOSQWaRuDMbx4+d8Drj3EAploAwClGILKOTelHYq62ORL0Q5574ffvgSMpT9oHQZ/0+16 UGD/GD0L /dwXlCiZv0bn+rD3GR7lmbWYuTb8pIRaM5o/t9g39PG8vhAZt81S63Ckm0eQ6yFvOJRRTfV6mS4i4GaJ/oL9eEG4YRGlzHYZi5ilHl7SHMsgFclYJ7B//OIATdxSvJIgCNn0VcXYa24JzPSIpmeNVfjMSdw== 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 20/01/2024 16:39, Matthew Wilcox wrote: > 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 > > ? There is a general problem though that there is a trade-off between abutting VMAs, and aligning them to PMD boundaries. This patch has decided that in general the latter is preferable. The case I'm hitting is special though, in that both requirements could be achieved but currently are not. The below fixes it, but I feel like there should be some bitwise magic that would give the correct answer without the conditional - but my head is gone and I can't see it. Any thoughts? Beyond this, though, there is also a latent bug where the offset provided to mmap() is carried all the way through to the get_unmapped_area() impelementation, even for MAP_ANONYMOUS - I'm pretty sure we should be force-zeroing it for MAP_ANONYMOUS? Certainly before this change, for arches that use the default get_unmapped_area(), any non-zero offset would not have been used. But this change starts using it, which is incorrect. That said, there are some arches that override the default get_unmapped_area() and do use the offset. So I'm not sure if this is a bug or a feature that user space can pass an arbitrary value to the implementation for anon memory?? Finally, the second test failure I reported (ksm_tests) is actually caused by a bug in the test code, but provoked by this change. So I'll send out a fix for the test code separately. diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 4f542444a91f..68ac54117c77 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -632,7 +632,7 @@ static unsigned long __thp_get_unmapped_area(struct file *filp, { loff_t off_end = off + len; loff_t off_align = round_up(off, size); - unsigned long len_pad, ret; + unsigned long len_pad, ret, off_sub; if (off_end <= off_align || (off_end - off_align) < size) return 0; @@ -658,7 +658,13 @@ static unsigned long __thp_get_unmapped_area(struct file *filp, if (ret == addr) return addr; - ret += (off - ret) & (size - 1); + off_sub = (off - ret) & (size - 1); + + if (current->mm->get_unmapped_area == arch_get_unmapped_area_topdown && + !off_sub) + return ret + size; + + ret += off_sub; return ret; }