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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 989D5C001E0 for ; Tue, 15 Aug 2023 02:26:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234206AbjHOCZa (ORCPT ); Mon, 14 Aug 2023 22:25:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233747AbjHOCY5 (ORCPT ); Mon, 14 Aug 2023 22:24:57 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC72310C1 for ; Mon, 14 Aug 2023 19:24:55 -0700 (PDT) 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=jGHqBFoHTGGxthfJ8DuweAb418DGrKcXt4a8moA6GQI=; b=PVDVlReZKuqzSo8dh817AjyvoY viyUIzFCHLMs6nOZEwBLcFpDo9T0ApL1NTCn2F0SxHmhVmPCYYtvs6dME31R6RP2gpn22J57JwUZc 0jSS/CRJ0eJyupc0O1il2UGCRj2XSA/WTwc0BTi3BDULnQUX9tTYRvzJ0vogFaPCXSq7+7tNjPg4K nMO/EnIU7RoZVPMXk9cyq3uyeB2vDD0dHk6jVgYWKcMxINZ6O/TgqQ77vWI9QGGlzyX2eJwz+FHFl q2bTLJ2vfELgc5JquYvhpljVGLW/KF34q9ItZYlynJtJVax8u9eThdW+7VCyXVnNmfuMBjbncyCap UcTROjtw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qVjjf-005azd-HJ; Tue, 15 Aug 2023 02:24:43 +0000 Date: Tue, 15 Aug 2023 03:24:43 +0100 From: Matthew Wilcox To: Zach O'Keefe Cc: Saurabh Singh Sengar , Dan Williams , "linux-mm@kvack.org" , Yang Shi , "linux-kernel@vger.kernel.org" Subject: Re: [EXTERNAL] [PATCH] mm/thp: fix "mm: thp: kill __transhuge_page_enabled()" Message-ID: References: <20230812210053.2325091-1-zokeefe@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 14, 2023 at 05:04:47PM -0700, Zach O'Keefe wrote: > > From a large folios perspective, filesystems do not implement a special > > handler. They call filemap_fault() (directly or indirectly) from their > > ->fault handler. If there is already a folio in the page cache which > > satisfies this fault, we insert it into the page tables (no matter what > > size it is). If there is no folio, we call readahead to populate that > > index in the page cache, and probably some other indices around it. > > That's do_sync_mmap_readahead(). > > > > If you look at that, you'll see that we check the VM_HUGEPAGE flag, and > > if set we align to a PMD boundary and read two PMD-size pages (so that we > > can do async readahead for the second page, if we're doing a linear scan). > > If the VM_HUGEPAGE flag isn't set, we'll use the readahead algorithm to > > decide how large the folio should be that we're reading into; if it's a > > random read workload, we'll stick to order-0 pages, but if we're getting > > good hit rate from the linear scan, we'll increase the size (although > > we won't go past PMD size) > > > > There's also the ->map_pages() optimisation which handles page faults > > locklessly, and will fail back to ->fault() if there's even a light > > breeze. I don't think that's of any particular use in answering your > > question, so I'm not going into details about it. > > > > I'm not sure I understand the code that's being modified well enough to > > be able to give you a straight answer to your question, but hopefully > > this is helpful to you. > > Thank you, this was great info. I had thought, incorrectly, that large > folio work would eventually tie into that ->huge_fault() handler > (should be dax_huge_fault() ?) > > If that's the case, then faulting file-backed, non-DAX memory as > (pmd-mapped-)THPs isn't supported at all, and no fault lies with the > aforementioned patches. Ah, wait, hang on. You absolutely can get a PMD mapping by calling into ->fault. Look at how finish_fault() works: if (pmd_none(*vmf->pmd)) { if (PageTransCompound(page)) { ret = do_set_pmd(vmf, page); if (ret != VM_FAULT_FALLBACK) return ret; } if (vmf->prealloc_pte) pmd_install(vma->vm_mm, vmf->pmd, &vmf->prealloc_pte); So if we find a large folio that is PMD mappable, and there's nothing at vmf->pmd, we install a PMD-sized mapping at that spot. If that fails, we install the preallocated PTE table at vmf->pmd and continue to trying set one or more PTEs to satisfy this page fault. So why, you may be asking, do we have ->huge_fault. Well, you should ask the clown who did commit b96375f74a6d ... in fairness to me, finish_fault() did not exist at the time, and the ability to return a PMD-sized page was added later.