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 297A1C2BBCA for ; Tue, 25 Jun 2024 13:06:51 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uJ7hWaXxJ9nttN5wvvdvZmPC2/6Vfv3y1uigVrqH7Wc=; b=HT+8Zy0gvg6z4wss+KDcU9kBZX vE8g4LNB9YtMNuGRYPmA7uM4bCLBPW9xN4dtUJiAbS9qCPb0lwrtRv77KzjkCgzNauOYpWQauXM01 +ETRNimG6ADijxeLKSS3wIPMzi3eMoxW21IbH12DwISpBSZElxMnKUff1AbPZ4MrqQPBIn1an9G2d WNa8nPyZEWnUDZWA4Z14tNDTim5XjSCakRB/FU73zeCFZD0DfvmPC0onACI4AXBlBU6TxY6tzHnqk VHksbLgIWlfnYBMY7O/wiyD1FWlXYmr01qF80XTE3RVSdct4BT89PhR/N7RVfDe0MJOErRKr3jNFf +OyJDx3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sM5sc-00000002uLR-1Uxi; Tue, 25 Jun 2024 13:06:38 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sM5sX-00000002uKz-1reH for linux-arm-kernel@bombadil.infradead.org; Tue, 25 Jun 2024 13:06:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=uJ7hWaXxJ9nttN5wvvdvZmPC2/6Vfv3y1uigVrqH7Wc=; b=nhr9RXwE9gNy4OxfhLEOHIpamL ye0Qbn2AedJX6y4THUoBgdvfvgo9EoOXhpHNkr5KOyNeEYUNfojioKzG53I5Isac2gb3KmmXWr9Zv iipNwIsmmgeCD+gjub6Emqg3hsQjwg235rTqbYqIWFgdhFJjNt9D7L8hHkCtC4EGDE1NsQoaJRVfH 2UD4DYd/tDzYBRypix7EfPaqFY/yCRCa9rvOkywadiqHZIhy5thxRuFNFmmIS/OJ3hZpWX1tYP8+y j3kQsfHW6IcNO6ibjv9VsKWHV+24TrZNPzM5JiScsOesw0xXV2GIbpcVqn4b73l4YN/goXk1oYKmQ 0ZIYEO7Q==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sM5sM-0000000B9hI-2XAv; Tue, 25 Jun 2024 13:06:22 +0000 Date: Tue, 25 Jun 2024 14:06:22 +0100 From: Matthew Wilcox To: Ryan Roberts Cc: Baolin Wang , Kefeng Wang , Catalin Marinas , Will Deacon , Ard Biesheuvel , Marc Zyngier , James Morse , Andrey Ryabinin , Andrew Morton , 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" , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 18/18] arm64/mm: Automatically fold contpte mappings Message-ID: 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> <306874fe-9bc1-4dec-a856-0125e4541971@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <306874fe-9bc1-4dec-a856-0125e4541971@arm.com> 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 Tue, Jun 25, 2024 at 01:41:02PM +0100, Ryan Roberts wrote: > 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. mmap() faults also use readahead. filemap_fault(): folio = filemap_get_folio(mapping, index); if (likely(!IS_ERR(folio))) { if (!(vmf->flags & FAULT_FLAG_TRIED)) fpin = do_async_mmap_readahead(vmf, folio); which does: if (folio_test_readahead(folio)) { fpin = maybe_unlock_mmap_for_io(vmf, fpin); page_cache_async_ra(&ractl, folio, ra->ra_pages); which has been there in one form or another since 2007 (3ea89ee86a82).