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 B81D5E7717D for ; Mon, 9 Dec 2024 11:52:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D2696B0421; Mon, 9 Dec 2024 06:52:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 481FB6B0422; Mon, 9 Dec 2024 06:52:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 349A56B0423; Mon, 9 Dec 2024 06:52:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 161706B0421 for ; Mon, 9 Dec 2024 06:52:44 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 89C7C1A0466 for ; Mon, 9 Dec 2024 11:52:43 +0000 (UTC) X-FDA: 82875258438.14.A7AF0A6 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf11.hostedemail.com (Postfix) with ESMTP id 9000140003 for ; Mon, 9 Dec 2024 11:52:21 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733745142; a=rsa-sha256; cv=none; b=wTCwLdJLcQSZzgmlPvKLY1Hw1t5aW173ENf6tWhB90AKn4wFK9FjhIVbyfdZ9TgSuVDMdf XKEQ+sCAZxKy3vu6IStLWBsb8Lb2Jhnrkzke/wNsuxXoXLiaTX/LtdbDb6pHQxtu727aDr OMjGQ5cs+TdtsgdsNVFdfgubEYCYfYU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733745142; 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=neKGYCj3thbp4sfIrOAqlEUFEHIV+XoVIj1WpwQgDCk=; b=VmjR6rUo5j7kB3xVrmRkYl+CaJEtQYukteCmTZOblR019sfb1TfAWlh8HGrfLRrbe3Oejx 1OrbEW0vHzj+M5nn/0E+w8Om7NuCfGf9nEoKph+WvBMqZxQT+6acsw/29JCGr/JtJPneye dlrFrmPK8G2WVHEx7jitdBZdEcOQNyY= Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Y6KtG07Xsz1kvkT; Mon, 9 Dec 2024 19:50:14 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 2534D14011D; Mon, 9 Dec 2024 19:52:37 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 9 Dec 2024 19:52:36 +0800 Message-ID: Date: Mon, 9 Dec 2024 19:52:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH -next] mm: don't try THP align for FS without get_unmapped_area To: Vlastimil Babka , Andrew Morton CC: "Liam R. Howlett" , Lorenzo Stoakes , Jann Horn , Christophe Leroy , Rick Edgecombe , , Yang Shi , David Hildenbrand , Ryan Roberts References: <20241206070345.2526501-1-wangkefeng.wang@huawei.com> <20241206223456.255b00b35cb554987e48daae@linux-foundation.org> <59025011-0525-49d2-9dd9-e275991748ad@huawei.com> <32c2aae0-37e2-46c7-87a1-075ead14dd89@suse.cz> Content-Language: en-US From: Kefeng Wang In-Reply-To: <32c2aae0-37e2-46c7-87a1-075ead14dd89@suse.cz> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9000140003 X-Stat-Signature: 7x5syozpbjse8zdfszdt13mj4jy3jsu3 X-Rspam-User: X-HE-Tag: 1733745141-786539 X-HE-Meta: U2FsdGVkX1/2WB2UVlvCU/IUKbnTXrorbf3Z+fQwDbjXpPjz1cSdT6Gx0V6cacPLzRROSu/HhydCOow9N7/xasWGGkVnGQGDTL4J0G1N4lB+soqc8zQw883C54V6YRFm621rImrFxlxqvpDpMGTMbd/ptC1q6GU6gqWTOVFw6SJVPLhtQEBY1E02k1W8lwg044IQGcILtohlmbHtBSk2mZcyI6/i+8lDLDGRGN4N6WTfW5q+srlhomH4f/sSqfHOvWoBGPF1B7TrAB2nrVJRKUlBZ67qjTSx9O/jYNg5LFKTkdNSnoMrVQd9j7YdWfibQT34sCNjcRS9YHD/kan0fKuRtYSZMeREDvB9U6njD4gYeFrcau1nqrhvkknMJxXZKLEbS1Ud/8VXgPAk0yDzAlvd1CY7RAaQytup3QIqirO5LIPSmYyiWPHnzenUVBhsTVVxr2dwjVKXZVE0E0UhB20GnLEWQsFWV6CPprG9ed7z7SQTG6CmdJiKYq0BSWIdaH8GBr/KoK2aU3ibFC0ouXyiMIMpfK/EJNTw3mAxKyc6PJ5pZmHWUWpQsEEfIWLvZfbEkE/PVq9/dKVBuB08G3iIpH8fjXnRpZeK64q8PF6m7D1N5goGJbBLYbDZydu93mWGw2acNSDzWpUumXtr2XhDChYPFGD3LP5qkWfEFExQCo9v8DmpXucFHiZwkLCWN4RYAaVLeHUhmBvjdjKCy/VP8J1tm5qK+E0x1p2W+e6UNbjVOxwMunR33MBVtjRP3INteIWXE4kShUfCt/jYoVKR99q2h7KqqOeJ92p8TT9P2VzP5Aa6OgtM/K43fXWB4WKBSgm47DbF3hRd9bHqXJb4WDoERvi0cJOur6aWKeloAmY7uEC0Zb2yJiQEl5ETv3RCf8ZZ9tbc9GCtol3vQeVVjwLWNBTIX8znjxxZyGKF5JqL3zuOwHhhZjS27ucRBwQ5qvoFgqWY3vpoC1+ WrXCV4Tg 6v44On7M8qLuDMWtZsqjGHqjtbpqfMLnkmilOjtarGjXw3185GDQxwjIXCy7PGlAkRHj6QQyKCQIcQQ42b5FD/dDlvqQQ4MPUeIcU9KSy3PN+IcDESawRGVQ4nWAZP68yoJJtmwEFcT8/OQs8cIFjwYvScSQmuID1/dW7ty2tsPNoMurctG7n2K/+zHD1nglekq+jA2TJUcns34ynTBuEv098nn0QzAfo0nI1vgDYrgAcjng= 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 2024/12/9 16:36, Vlastimil Babka wrote: > On 12/9/24 06:00, Kefeng Wang wrote: >> >> >> On 2024/12/7 14:34, Andrew Morton wrote: >>> On Fri, 6 Dec 2024 15:03:45 +0800 Kefeng Wang wrote: >>> >>>> Commit ed48e87c7df3 ("thp: add thp_get_unmapped_area_vmflags()") >>>> changes thp_get_unmapped_area() to thp_get_unmapped_area_vmflags() >>>> in __get_unmapped_area(), which won't setup get_area for anonymous >>>> mappings, but it leads to always try THP align when file ops without >>>> '.get_unmapped_area' callback too as the get_area is NULL. >>>> >>>> Since commit efa7df3e3bb5 ("mm: align larger anonymous mappings on >>>> THP boundaries") only want to enable THP align for anonymous, adding >>>> !file check to fix it. >>> >>> The above is tough. I attempted a rewrite, please review for accuracy >>> and completeness: >> >> Forgive my English, thanks for rewriting the better changelog. >>> >>> : Commit ed48e87c7df3 ("thp: add thp_get_unmapped_area_vmflags()") changes >>> : thp_get_unmapped_area() to thp_get_unmapped_area_vmflags() in >>> : __get_unmapped_area(), which doesn't initialize local get_area for >>> : anonymous mappings. This leads to us always trying THP alignment even for >>> : file_operations which have a NULL ->get_unmapped_area() callback. >>> : >>> : Since commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP >>> : boundaries") we only want to enable THP alignment for anonymous mappings, >>> : so add a !file check to avoid attempting THP alignment for file mappings. >>> >>> Also, the changelog failed to describe the userspace-visible effects of >>> the flaw, which is basically essential when fixing bugs. >>> >>> The bug has been there since 6.10 so it would be interesting to learn >>> why it took this long to be noticed. >> >> Found issue by code inspection. THP alignment is used for easy or more >> pmd mappings, from vma side, I don't think it will introduce usespace- >> visible effects, only different vma address, but I don't know if there's >> any other effect. > > How about: > > This may cause unnecessary VMA fragmentation and potentially worse > performance on filesystems that do not actually support THPs and thus cannot > benefit from the alignment. Thanks for your update, yes, like efa7df3e3bb5, there is performance regression for align anonymous mapping before. Hi Andrew, please help to squash above part into the changelog, thanks.