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 F1ECEC30653 for ; Thu, 4 Jul 2024 15:54:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 693E86B0085; Thu, 4 Jul 2024 11:54:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61C8C6B0088; Thu, 4 Jul 2024 11:54:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E4436B008A; Thu, 4 Jul 2024 11:54:59 -0400 (EDT) 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 2F28A6B0085 for ; Thu, 4 Jul 2024 11:54:59 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9C94681393 for ; Thu, 4 Jul 2024 15:54:58 +0000 (UTC) X-FDA: 82302518676.29.5096C1D Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf11.hostedemail.com (Postfix) with ESMTP id E7EA840014 for ; Thu, 4 Jul 2024 15:54:56 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720108484; a=rsa-sha256; cv=none; b=CqDJiDxlgb8VRUANyk8sqVqDIINgRw1ViA/xp6lLRwgwnED0FJEtUcLwLIBi5bzxgCGrP7 17RLy2mLEv/SNamuIWUB7kSQuNf4AGsyn/CWTdKtCqXOsF+SVW7QopN2seRYoUNuauR6BB ov1C46Q+1zttn9KtF0KauS/8QbR8G/E= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720108484; 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=vDpOROJUrP5EGtnpyukeOW5L86LrlHPoTYRF0XO2GR8=; b=8Ol2hzULCi7DcGFOtGep4MiPfG6oXWSbOLw27ZaxZ5w7/KiOGC5Rre5Bb0q8ILT+dnEN3Q 3c2ar8prv1d2kiW26oVdDhj4YuYmRb28RiE22jqVAK48NCPoJZRzGW/6Lzhixa/ex/8A4u ItfRAfSa0PiboDZIwVvhqqvQ/6w49ZM= 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 5E862367; Thu, 4 Jul 2024 08:55:21 -0700 (PDT) Received: from [10.1.29.168] (XHFQ2J9959.cambridge.arm.com [10.1.29.168]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F399A3F762; Thu, 4 Jul 2024 08:54:53 -0700 (PDT) Message-ID: Date: Thu, 4 Jul 2024 16:54:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 4/6] mm: shmem: add mTHP support for anonymous shmem Content-Language: en-GB To: Bang Li , Baolin Wang , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, david@redhat.com, wangkefeng.wang@huawei.com, ying.huang@intel.com, 21cnbao@gmail.com, shy828301@gmail.com, ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com, p.raghav@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <65796c1e72e51e15f3410195b5c2d5b6c160d411.1718090413.git.baolin.wang@linux.alibaba.com> <65c37315-2741-481f-b433-cec35ef1af35@arm.com> <475332ea-a80b-421c-855e-a663d1d5bfc7@linux.alibaba.com> <33d04365-c129-453e-b3b3-0691cfecd36e@gmail.com> From: Ryan Roberts In-Reply-To: <33d04365-c129-453e-b3b3-0691cfecd36e@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: jpwnwzensww6j4gff7ar8k77t6ixok93 X-Rspamd-Queue-Id: E7EA840014 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1720108496-414370 X-HE-Meta: U2FsdGVkX1+Qrhhpt6w/O+UvikBeErq+K3ovvA6DBCNs4HTOfW0Udl/jtaXk1yMK4qnniFpuR9xsGZuT1NjJzB0b0Qd2fE06XwG/hJA9vuF80AwY2ykW1OUIZd03IdXOTyIa6x+0ss6c8a66IIjGlO0piZplydnKDqljmnbSXfgvoppG9VxPnyYvkVOB6ywQB0D3a5Ch39rGT+61geVwtjIzHUdFT+prCbDf50oEcsTJt/RhywGG36i5soZR7X/F+cLUKr4Io8veGCIT360c4XZzSjToBcC549R3uIhOP61DG3+Dofij03mSgyMKYJrBU7SDaliAoC6Uo8ao0zZ43nDvUqN3802FqXQ7Me9VfdMKlFkDwIK1chr9pkVF4q2oqYfq4TM7WhTsJdkmOnEgVg6gZlKO2eLbtaFkiT3JU9Y3cPBe3HAcCYEjVRLmfQJ/fzboSmcZLamY2a5DUbmwgDN9Ffh54i5012Rxggggqoo79ANlZiD8sUz5qf8yOh9hS+3whTRpA/pUE99kg7vRd5iRTL2DqMHhEttgKsuY9eOYzlLCcRh4zeMKr5JPfmZAcxX/HCoivuKei7v3UBp3+Qt0dA5wrcmBiQ42ERyMruoO0y7aiHq/+t80dLomWPAHK0TaUaUHF6eORm5BcE/Dse1k84Or/E1W5WmJ8JEBmDYtNnlLZFFCi5kVn6SOChCP33cO1HoqgARAQLa398AK9KNAotKfdozIMLQH51bXlMjPcATMjiRXPtdNoAOFTE5bUAXz0mBBF/GDHj5zgvz05lszlPi8wL4aR1QsHidn3vWLxcCieQu7niJdMNpN+7s1bil8O24wfx9LrOTzhDInrq8jsNB8aAMnzfovtNZ1YW/J99/PXm73vKf75Jc+bN9o1kGxibcsT2+rPgsJzZB6YdK2Q2S5ItkBA+sS4j0BVko/V2wPE/wyTU/s+BSf0SahKKi/fWDVTRuQGjHERyx ZUF5aDPY DF0wfyJZGviwL04mXsc5wlaB9qtSaYl/H4glVedjsOgblvZyZKT8945emofBTz48Wl5wzf2FCvXYM47UkCBTzLZdsFteIYPRczGfv8JERZAZYy3TEG35HJMd+I64Q6+Ryv4FU2zFYXus2Dzw5eGnSwnft/e4F72PN7GxhlsLrLB58BVewUcRzyECoJLXQxMyHd6XNyMpfrYmnRrdhw+V2UFpldbNaYYQGgXPpwsZsBf1c9w8lbyuODIGEntvYWZB8Fw4mH6S4X2PGbVfoVvv+Z6Aow2qEgTum4/SNXeauwGkKu/7a/zmKeC+waJ1/Eu7fIXYvOSzMGvGWVaytgOmIM8/Fs8uAEXLSDnajSZxsSrz1Klg= 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 04/07/2024 16:05, Bang Li wrote: > Hey Ryan, > > On 2024/7/4 21:58, Ryan Roberts wrote: >>>> Then for tmpfs, which doesn't support non-PMD-sizes yet, we just always use the >>>> PMD-size control for decisions. >>>> >>>> I'm also really struggling with the concept of shmem_is_huge() existing along >>>> side shmem_allowable_huge_orders(). Surely this needs to all be refactored into >>>> shmem_allowable_huge_orders()? >>> I understood. But now they serve different purposes: shmem_is_huge() will be >>> used to check the huge orders for the top level, for*tmpfs*  and anon shmem; >>> whereas shmem_allowable_huge_orders() will only be used to check the per-size >>> huge orders for anon shmem (excluding tmpfs now). However, as I plan to add mTHP >>> support for tmpfs, I think we can perform some cleanups. >>> >>>>> +    /* Allow mTHP that will be fully within i_size. */ >>>>> +    order = highest_order(within_size_orders); >>>>> +    while (within_size_orders) { >>>>> +        index = round_up(index + 1, order); >>>>> +        i_size = round_up(i_size_read(inode), PAGE_SIZE); >>>>> +        if (i_size >> PAGE_SHIFT >= index) { >>>>> +            mask |= within_size_orders; >>>>> +            break; >>>>> +        } >>>>> + >>>>> +        order = next_order(&within_size_orders, order); >>>>> +    } >>>>> + >>>>> +    if (vm_flags & VM_HUGEPAGE) >>>>> +        mask |= READ_ONCE(huge_shmem_orders_madvise); >>>>> + >>>>> +    if (global_huge) >>>> Perhaps I've misunderstood global_huge, but I think its just the return value >>>> from shmem_is_huge()? But you're also using shmem_huge directly in this >>> Yes. >>> >>>> function. I find it all rather confusing. >>> I think I have explained why need these logics as above. Since mTHP support for >>> shmem has just started (tmpfs is still in progress). I will make it more clear >>> in the following patches. >> OK as long as you have a plan for the clean up, that's good enough for me. > > Can I continue to push the following patch [1]? When other types of shmem mTHP > are supported, we will perform cleanups uniformly. I guess that makes sense. > > [1] https://lore.kernel.org/linux-mm/20240702023401.41553-1-libang.li@antgroup.com/ > > Thanks, > Bang