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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 970C4C3064D for ; Tue, 25 Jun 2024 12:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9CcLCOccFhfBPz2VhaI307IjIn69/hoFG5OuPLpt8TM=; b=Nk/XlCdvc8eWP00SKHrgJbQ9Ok xUNcqd5L65ADs7i7gdPqjNQw4YKOdXGXclf53V70EvISGZEdceRSB3B8HqnRD2LaEL3pDjJYCoATw XVWf9b/6AussUUGIilCqRxDoCqU/f0pwZOuiV7uJFDbfq4+05TF7zbPvydJ4agpKdBEEqbD0jLTwy 0xsaV2jTva+rYkRawI7aDeKQ2atB6CLMGn98x0zpgnJobVf25SNH+91AJpLTzDzhjGCNFr8/Go7un EWmzxAcLP/Lj62iT/B9CO7cj4sFJjsIo8BZGOqsolRmZp4g6leddmEMbFARpsddR+dPf+QB4d6wsu zVq68azA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sM5U4-00000002pWX-08Vk; Tue, 25 Jun 2024 12:41:16 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sM5Tx-00000002pU6-3GNM for linux-arm-kernel@lists.infradead.org; Tue, 25 Jun 2024 12:41:11 +0000 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 50EFA339; Tue, 25 Jun 2024 05:41:33 -0700 (PDT) Received: from [10.1.39.170] (XHFQ2J9959.cambridge.arm.com [10.1.39.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 774F33F766; Tue, 25 Jun 2024 05:41:04 -0700 (PDT) Message-ID: <306874fe-9bc1-4dec-a856-0125e4541971@arm.com> Date: Tue, 25 Jun 2024 13:41:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 18/18] arm64/mm: Automatically fold contpte mappings Content-Language: en-GB To: Baolin Wang , Kefeng Wang , Catalin Marinas , Will Deacon , Ard Biesheuvel , Marc Zyngier , James Morse , Andrey Ryabinin , Andrew Morton , Matthew Wilcox , Mark Rutland , David Hildenbrand , John Hubbard , Zi Yan , Barry Song <21cnbao@gmail.com>, Alistair Popple , Yang Shi , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , "Yin, Fengwei" Cc: linux-arm-kernel@lists.infradead.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240215103205.2607016-1-ryan.roberts@arm.com> <20240215103205.2607016-19-ryan.roberts@arm.com> <1285eb59-fcc3-4db8-9dd9-e7c4d82b1be0@huawei.com> <8d57ed0d-fdd0-4fc6-b9f1-a6ac11ce93ce@arm.com> <018b5e83-789e-480f-82c8-a64515cdd14a@huawei.com> <43a5986a-52ea-4090-9333-90af137a4735@linux.alibaba.com> From: Ryan Roberts In-Reply-To: <43a5986a-52ea-4090-9333-90af137a4735@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240625_054109_976424_B63121AE X-CRM114-Status: UNSURE ( 9.63 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 25/06/2024 13:37, Baolin Wang wrote: [...] >>> For other filesystems, like ext4, I did not found the logic to determin what >>> size of folio to allocate in writable mmap() path >> >> Yes I'd be keen to understand this to. When I was doing contpte, page cache >> would only allocate large folios for readahead. So that's why I wouldn't have > > You mean non-large folios, right? No I mean that at the time I wrote contpte, the policy was to allocate an order-0 folio for any writes that missed in the page cache, and allocate large folios only when doing readahead from storage into page cache. The test that is regressing is doing writes.