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 8FDB9EB64DD for ; Mon, 14 Aug 2023 19:06:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA279900009; Mon, 14 Aug 2023 15:06:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E52B2900003; Mon, 14 Aug 2023 15:06:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D416A900009; Mon, 14 Aug 2023 15:06:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BE6A3900003 for ; Mon, 14 Aug 2023 15:06:21 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2E5CC1C9AE5 for ; Mon, 14 Aug 2023 19:06:21 +0000 (UTC) X-FDA: 81123640962.10.202BA42 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id C22F2120029 for ; Mon, 14 Aug 2023 19:06:18 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=m6hGr6cd; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692039979; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Pv/oJkWDSXTVoPVR7KmdoJv2HB07fea1hw76M762x3k=; b=WWwKS0feQECRUjKMZDuy/IKfE7gmvgSEbBYoPAPlUlhX1m30uIa1VtO2vW0vIS3NsiScuU Zie5kGpVKbcdf2yOLp4PSByR70KeJ8v0+QLpxdIBmhtRAz2qUbOHTVJj7GgW1FNvXMi4at yEsoxSuoofeBwKZaGEn87U9//ZkN180= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692039979; a=rsa-sha256; cv=none; b=dOsWHmh1kd+az6cFvl1sz5b1col/ibbmcT0E/ExBM0tj2el2lZHjE+gz7xDwCZMcIN7Vzs XK3deiZZax/EiA9QIShiwiFF/llBIECbNr4QHubLpsT6lbXATMOOcj4hDx4+/o5ARczyTE odNRLPbPsgIZM6fNsWtF83uZNI0Q8iw= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=m6hGr6cd; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=Pv/oJkWDSXTVoPVR7KmdoJv2HB07fea1hw76M762x3k=; b=m6hGr6cdg4oW3bNsImeckK9GLj Ve6uDVbHHzBTj44X52+cNApSIVJMg3GUMoUHFdksGMIo/ZpIDD2bdVGXiFMBbe/gIyEeLedQYiwRW zaPomdWFsWK7dul0BCFzQBvG1T5O4xq0IoYUWr7++Ug2fsez79fMhltiYTSNcA3HiAwqy8pDId0P9 7l/I6bib0vfxGbSKyO/RxuIOjea2rDmE7OQ1+uTL2GiwDeyeKmW2N5EkR2q4Uaxt028Fmfb2pULPB Qf9qLq7WcxSMsO6Sro9ZqFB6HffJBmAXLuojwOcrpOaaLLmEeM3UjzLTh9ucnYdsxuiEDQlLO1L1G ulxMhamg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qVctI-003iSn-R4; Mon, 14 Aug 2023 19:06:12 +0000 Date: Mon, 14 Aug 2023 20:06:12 +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: X-Rspamd-Queue-Id: C22F2120029 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 8zk8hhkpkcffodz974h6qzkrtekdej99 X-HE-Tag: 1692039978-540673 X-HE-Meta: U2FsdGVkX1/bCaf7GtZsSiuXwwd1x0NcNnBxj2p0+T0yf9RfPD6EntlSTuZORVZOzdiDYe/91+RetrinwrWT95D36zEL3a4vBzWzEkGEqwrYuweDLVZEaO0mHqjeaE+vnO9n1oUHGkt+6haKHZ3UUmnQ+ACMHKt3Av3o3sf/LjtqOQAfkTmDQ19dMIecI1n4IlFTsME/ZzLWE18EgNFvy5wYELJkiJyy4+IhkC7pHw+NmNM3sGK/0Ae34mtwCjde5agsb4+Bw7NrfKbYBONDM8DdYnMoRfu4+uKWcPKC90ZYSadCHPbdzdtFqVGi67bgQg6T3R2wmuAZHbfSmZQ0ASBAGqagzxs/N9t7y2Vu5VYpolfduKpeDr2I4n5Fh9KhZIfI9SCcKVCPOldyAeerT49sStaDjP56eA0tdsVIWWnRJ9mHx5Aswsu7IX8tOzoTAbm4QHM3lqMAmFrnvDJVRpRrd5WwID2NLLGEkX7ZZ/XRj1jyxBYLrxzcS2FHtHJRkTpg5fGRCFxs+OtocLVXB6YpEyLuA7r1y8UrMr44323FF0j2gPi7/1BslH4E+uKnACgUgwDfrp+48Pfyjo1bwutgKyCJhtgZCc51ZUrMZWZwOsX89Dx4glHdIw+maUjue9Bm5rM9jnxNfia2JknoBdia05FHgnpZv9dRuB1I/CSFuJikBo6etew7+tjo3YC9Vy8tKv4smvSgyHcdgifyKyAkLhH5X/l45dSxGX+rG2fccMnt9XKuOMvZ2WYJyL5UVDT9aS344fv640DsRWmklijMyGdwieA2ncYV5R/wBPImLReGODejYfQ/l0W4yrmuf3fZOdc9hqMi7KZhmdipTQijdRecjfiydB2r2Fbcg/ncrrGRrYmAGPvyVtq8VZpRlNP4enZxedEphj0+K1r3Tk46CCiq8kKBcxvjafIlaiqcjZNOPoJ3llRBTC8p3UBbZFF/Ts/GkYTjpMDY4OB lV54qzDK PzTwOMl8dcrIT0eA/5ksCSZKO0+baZzEe9OeVsmuByjnt7spvXjLD4derd9uIZn0lB4dZg9hiV2wWl7jth8TTopGovWAzLiNmYYd71FwT2+t6UmU6MyrnNcz96sDfK/+UCs51vgEW0pHcQlmerU1mT+4EJnqb3QjpQXzn55nVErxnGY71DkLnkURLA6teWpRFI47CSfi7n0RZvaAwMyF0qJw8wEIYd8CYVEjA 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: On Mon, Aug 14, 2023 at 11:47:50AM -0700, Zach O'Keefe wrote: > Willy -- I'm not up-to-date on what is happening on the THP-fs front. > Should we be checking for a ->huge_fault handler here? Oh, thank goodness, I thought you were cc'ing me to ask a DAX question ... >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.