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 1AF98C001E0 for ; Tue, 15 Aug 2023 00:05:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3304D90000D; Mon, 14 Aug 2023 20:05:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E0BC90000B; Mon, 14 Aug 2023 20:05:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A96990000D; Mon, 14 Aug 2023 20:05:28 -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 0DF7990000B for ; Mon, 14 Aug 2023 20:05:28 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C781E401D4 for ; Tue, 15 Aug 2023 00:05:27 +0000 (UTC) X-FDA: 81124394694.19.F770ACF Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf27.hostedemail.com (Postfix) with ESMTP id EAF5C40011 for ; Tue, 15 Aug 2023 00:05:25 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=3fV8hMPZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of zokeefe@google.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692057926; 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:dkim-signature; bh=qNAjR5087SyIRll55Tg36V4TelXhAR59suyGWAJNzX8=; b=igag0RsglnG0h+A5YjOrlRqfv41FRh0v9hsx9lpPDKzVrji56amMXgNyFcu9h5dY4PgTWy M2QTVWS0UzCunjGbO8bdAULM5YVJEBgOhAVYyi8G2eCwPjM/CqRACsUpq7JjzenT+T4sPq 1DjILWFLVju66cP7jD5quNRU4Ie0Cjw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=3fV8hMPZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of zokeefe@google.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692057926; a=rsa-sha256; cv=none; b=d9dlHDlT0HvmhLP7zA7Flr4ZVvKANT8hNsQnsKmoKqycjKDdvaM4ZOzb+kU9a5MEB7VFzs AJOzPpfuT3D8eeaKBa0SNZfH/S8vGhDw993a4L7VTQ51+LOQoZVUFk1iyqpiBYCsSL9mnD kw3dik0Sg6SfNaoyZ9UI+xSQ1enTQiM= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-3fe2a116565so21065e9.1 for ; Mon, 14 Aug 2023 17:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692057924; x=1692662724; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qNAjR5087SyIRll55Tg36V4TelXhAR59suyGWAJNzX8=; b=3fV8hMPZoERTZqelkQR6yMePUDw1HupWVsdS05m/eVlEIQbwYerQw570ZbEIGRLIXJ MGSLJ5s0UQ/hZOFrW46Cx4U+bDxv9PakJkfhmokntY7Sl4BC/JH344Sx5HlEarMHVE0L 8niUx6CLzy2xpPkuw9eobdzsLmy1R1qovfKrOfxBUo6IziwiYbcZtqoL8jP7fWnPFw4d cu923CWrrLe3U2eUx4Tts6yVDT+9Od4Sc/UxoBqtRzYWRzS73EPEWGxYuJIeUqEhgx9D 7CHfB5tu9AdtjKQ501QMyQKG8tRECMn3ijrNXSFx1zi8lXAjh4rxgXp0Sih/50xihe1w 5qBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692057924; x=1692662724; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qNAjR5087SyIRll55Tg36V4TelXhAR59suyGWAJNzX8=; b=BXh1cio9/C4lDSDbBzTCrZldRDjSzpTQdfhfq+UG937E9KUakMYYYqoMBevVxs+TIo yILPXLPjwk2qetvt+6m0T89SVNoz2JfHCgUpu41KDR581tiLk7velpz70Hsl0i3SRuOI S1aBHyRv2GxqN0cuut7RSlgusL0In3pJ3AtEOouQfQIl601DA5ETxqGu9WSewgxMFFpN sl/BCh4N4hTnl3IK5LG0WMQnW3OkxvDNSj7tj5pKy+NmtBSxD5oScM1REJlSqcRekMer H32jb5DfIswKBAdCWs7kFEri6HGXMvDXtiancKcHksOWc/6rI76zEHjGD6j3zpHq/olX s4Pw== X-Gm-Message-State: AOJu0YzqMqvIPkkZwd+YWxjB3tpOJvk6JkmTc0iuIzJk3PrGmNs2lGuz JXzsvWSRA+e1hwegsMx1vQ/qUKZR56pxDQoe5IWeog== X-Google-Smtp-Source: AGHT+IHe0RGOqaXy/zODryo9gaeKhb84uQYlaJaiaOBpufpAS/ZSJ7FSpEGgz/bwN9alEn8z85+2XyQImw0PYosguTk= X-Received: by 2002:a05:600c:3ba2:b0:3f7:3e85:36a with SMTP id n34-20020a05600c3ba200b003f73e85036amr334971wms.7.1692057924274; Mon, 14 Aug 2023 17:05:24 -0700 (PDT) MIME-Version: 1.0 References: <20230812210053.2325091-1-zokeefe@google.com> In-Reply-To: From: "Zach O'Keefe" Date: Mon, 14 Aug 2023 17:04:47 -0700 Message-ID: Subject: Re: [EXTERNAL] [PATCH] mm/thp: fix "mm: thp: kill __transhuge_page_enabled()" To: Matthew Wilcox Cc: Saurabh Singh Sengar , Dan Williams , "linux-mm@kvack.org" , Yang Shi , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EAF5C40011 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 6oahmqp78w1ox1jmuc64c3dhhbyhy7wu X-HE-Tag: 1692057925-345188 X-HE-Meta: U2FsdGVkX1/T6R/baHzDkhdAIh3OJtEfMD2ANi+PN9P1gT0utEx2wAEFTzKU3cxdRpHVC0K7K/3nOlrusqqTuYv1385YXLEzPv4S8jS9TAwV7t1FC38HtFVKdmXiEEywhHC/iijT7UMqVVehpFYppdWwNC2HMzBc555atwJ7AoOOIxI/YUCSYq2x83duYaMUjclTAgfIYpbvFS0axVt0cRdbWKaJLYvbacXYBE+8iaXtAjaw8xWmXIrbkN1W5gmG1mk8PCoFjN+YETxW+CfsVjLmivoFrlQnbQfPqWG/QwC+Z77mDz4v7Gxdc9NCsj21Usdthb7opsaXgQo2yWAl0HvEjnZQQV696OSEjdwXMZr+IBdY9jUgp+iZkmcOJYTZsuYF+yDqd1p3IozXX+EwQHNPBCGwbRZtywNT721iS9/K27sIBKINeFK3zNC1hst18UdH++SkWSDb8nZ6Lax6Y0WwXANcMWl/KgS8Y3X4qbbSmdXfbfwyOl03YpqG0kTQDKi0zzL1l456nZPHItw3Os/r/f5AYE4KIFKejm2vJ50FSBis5LecGM3h3s577ujEA/PZtSvtY6lXnGrIJAvJYIFs1ct8/xDemZE9yvDbxmVCBZU7A3dAocT40qTVGBSZNYaFgAYSOshVbg7Ht2l1tO6j+Gvt1L4YHPuZS2I4zd1fV57qaCaMmCw1TrPgTV+2ST26HlFiLFPr6VfvDnbXrv6RLO8QrNOKpKZTsq3ZSck0oZFt60wh/hEgC65p1FFXa8H5zgn8s8c6M8BqPAqhkTcZrT79HC5ynnGsDjxcEWwDTL4ZtJOjALft/8YHF8URN7+fLueh4IQxnkZwkh8j5uWtqgE4Eqp4QeC36zOAL+vWAN9KflEzePtGSm6EVpvx4zH0qOeTxkFzVj35nYzd+6u1ie2CIsDBNCLh4xN9ZieJkR641tuFKMNJM3/QAgJfPZlTF+us0+YStrBBDGE yLz62xph P2Y56Dkbt8508ZloeYkZirlNBEsiTr8V6MhvlWqNrWrVUBXnNoL7u6vHVGYMPjwwZd5nu/CDycJ+roHThcLK7/vKdNNUMzPVQvrPf4YwaotGDCpTIrc7+jKEczrSOxeSDFJ6O6mJNcsMG6lT1L9rREbOQlS7b3jYX+EslfTbvqHf8anVlSmlNdytif75xHPI7LuVmHFC1NLAsqEmGp77E0abXXoW47tpkscZsjj+Ims8XuYX8Y5nlIH2gwf3euxotwLdrJ6xDThmx92nzwdEverLLwcBQc6h9IEiXdfsVotcUNTg9ZPXb3L5T48/jfV8VqNt2s5ZOmi3YyvizKqCLPHN6KgLi/CpNc5seuXyC2rtliWgxya7Lyx4u5g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 12:06=E2=80=AFPM Matthew Wilcox wrote: > > 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. 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. Saurabh, perhaps you can elaborate on your use case a bit more, and how that anonymous check broke you? Best, Zach