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 7D916C46CD2 for ; Tue, 2 Jan 2024 06:53:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C8BDE6B0282; Tue, 2 Jan 2024 01:53:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C3BBA6B0284; Tue, 2 Jan 2024 01:53:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2B446B0285; Tue, 2 Jan 2024 01:53:47 -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 A07CD6B0282 for ; Tue, 2 Jan 2024 01:53:47 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 644C71204B6 for ; Tue, 2 Jan 2024 06:53:47 +0000 (UTC) X-FDA: 81633455694.18.BCBA19A Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf28.hostedemail.com (Postfix) with ESMTP id BE97FC0009 for ; Tue, 2 Jan 2024 06:53:44 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.35 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=1704178425; 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=fAVB7Ej5LdIGkQGmArWRbOruLRSQZVcA/yveXMa3fuI=; b=dawzenCyLvdSTxdSQsVBRWw5eT1TgObHcx5EnJbhIFGJQMBQH78HguG9aocPLe00XEPxYt 84CBv6audjnLpT3CdVDoX/i/fq7y9HZQXKc0y616EeIKOwKTUHkye1WobLs2h3X3bTY6z5 kasPqqypYrvBgHQ7rNKgTgFzEViXrig= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704178425; a=rsa-sha256; cv=none; b=FZ3FSOGc5MjHlysMXnHfiOgN3pnj1kjEtZ6kgmHYQR2TfOWog1oLfpxMBbtqAuLAOW3Y6M qspYZCjDZvZMiJe+0NCnveJixv5T81An+aHLgO0KGDQ337x7TGSFlDy0aUjMkWaZUYv0fl j4y2RW0yVwO0PUjcjIYSeAoM5czxWKw= Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4T43SD0wTlz1Q7NL; Tue, 2 Jan 2024 14:52:12 +0800 (CST) Received: from dggpemm100001.china.huawei.com (unknown [7.185.36.93]) by mail.maildlp.com (Postfix) with ESMTPS id 47C7E1A0199; Tue, 2 Jan 2024 14:53:22 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 2 Jan 2024 14:53:21 +0800 Message-ID: <9bb17dcd-4651-41d2-9982-4632147a82f8@huawei.com> Date: Tue, 2 Jan 2024 14:53:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: memory: use nth_page() in clear/copy_subpage() To: David Hildenbrand , Matthew Wilcox CC: Andrew Morton , , References: <20231229082207.60235-1-wangkefeng.wang@huawei.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm100001.china.huawei.com (7.185.36.93) X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: BE97FC0009 X-Stat-Signature: 1bjjhyiqwqmmdjb1xa4g63khpg1ircg1 X-Rspam-User: X-HE-Tag: 1704178424-756128 X-HE-Meta: U2FsdGVkX188CFmAU8wv/PfaEoVg82Joa+Pd7eDK+XtzPiz9kKsTAPOma+Ym4erbaF0vZ04UfxCuQ0Lb4CqjxiFg8zDA23Zlncq1QKxxUPtqTtQ0mfkrAXwoCr8JvRf98m8XtWEQlBG246xiBaokpdmfFrhC2Axv4wXW4r5QVwVFkP3uGso8DznErCSdmVA+UrGEkGft/bzaBVK4dRz/9TB6XZ7oeD3Su5FhLIaPtzbE9liOFWaWT56+kMmzgMMlAZ4/Utr6CP3ETTEsLSJmHJoqLJivRpNzczG5iwdYUnOIlA9qD4prVCgFvV2KpR8P1tT1kLfzAqCZZuDygvZbXoktecNe+pxb/qGwFQiCFeEeqscwnoYuakOdpEx92rm1SlSd6tG5UIDyebQKLSl7g5gJSfsUw0Mnl88HWP7B66OSrGamd3Zcq4CC+oz3LYSmr6YFECFk/wcXX6TkRcKWQVMVm90THsiRfzDBsJMVoL9I/t3h8UoWmkFuMG/NO96VqL8g+WdQqLAX81qSWJsYQcy6Yg9LuMmhCbnxDBmtL5sMIJ3JpDzM0EyiqOcZYggT4q/W7ptCapyuJ+ZdHpfVuG5AyItflDzpqMcF4lTALeEMZhTszrTyFx8thxvttYnNm9w+YaJgVeLFt6i7jf87HgptajLBK8VdTDlN3dN6QW0NLfJMuzNsqxOemkr6pL5a65dFoLBHboXtO6bgDN7xXFoD5lvcShvYuXrB8XCTtsSmrUbT1SuekxNWPvAFkA7h+Jo1fGowL0xtgbhpdIWOyPk8pU0poVPYHwQEfWbs/TlBdtnOgV8FHcl5/6QF2dZMraa6hniSsUVwFek25SG3ZD5yFqw6Qxjk3uRiwBt7Qfaz5w7FIDNEcAC6+QX8kvJZF2EzX7OA0CnEE1YP7SYtXN0CZQ8MuKWmmhOkTjyJIOg8vTTJfK90KqrMtOD5KSQm+sRPxaoJsDtLN+taWm+ TiVDjbfq qUxYZLSuR83EGohE616DIlkKyYzGO59TBXOZ8umh/3KJ+ItlJ5n0BV2rmSM1LYJXH+VFLu3lpqEFt4pQy4jCv4aRac5VZAck6FFisEJazAWOIzn+pOQlQbPwN+RsoqnxtEGt1nVXrMLyCcJ7VZgK6c32vFi5hLKsDVK4KxSsg32U26vuIriEsYHG2msmgzUn8DrSAPbLJQ9K98LtSugbnfRnwbw== 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 2023/12/29 19:15, David Hildenbrand wrote: > On 29.12.23 09:49, Matthew Wilcox wrote: >> On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote: >>> The clear and copy of huge gigantic page has converted to use nth_page() >>> to handle the possible discontinuous struct page(SPARSEMEM without >>> VMEMMAP), >>> but not change for the non-gigantic part, fix it too. >> >> Can there be discontiguities within a non-gigantic huge page?  My >> impression was that you can't have a discontiguity at such a small >> boundary. > > No, we can't. MAX_ORDER allocations from the buddy always completely fit > into a memory section. On ARM64, we have 32M(16*2M) HugeTLB, it maybe not within a mem section, right? But after v5.13 commit 782276b4d0ad ("arm64: Force SPARSEMEM_VMEMMAP as the only memory management model"), it looks only old lts, eg, 5.10 could meet this issue.