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 C2108C41513 for ; Thu, 17 Aug 2023 19:01:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C44028004E; Thu, 17 Aug 2023 15:01:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 574C4940009; Thu, 17 Aug 2023 15:01:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43CAD28004E; Thu, 17 Aug 2023 15:01:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 34DCE940009 for ; Thu, 17 Aug 2023 15:01:57 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F0B4C41102 for ; Thu, 17 Aug 2023 19:01:56 +0000 (UTC) X-FDA: 81134516232.25.E31B3ED Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id 634524004B for ; Thu, 17 Aug 2023 19:01:53 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EyNymHEP; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692298914; 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=RJpdT2TuLX3rRzXEHlG8PsweP6fxFNpA/3TiJp72Sck=; b=dk3M+q826V/Qrfh4wXW/4lA1qSQgrQTaowFyc2FzGFKAhVkADLwyZZAKYDCAW2Tf5jFP8b /fGtFlAeEOU5F0Q5NY9GFS8keVHJNePgpk1XRg9/gB328Xbqjme3NzHIvC9/UUxcb0bn7Y QVgUpajnKUUrsArsF2swOuIi4rIW8/I= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EyNymHEP; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692298914; a=rsa-sha256; cv=none; b=ObAxcS72rkFL5w0cte0m7Yxd1AaYmZL0HqiYwG9UhOpVvnuJo5IcR963hoziBUslMPNcMk xuY62fXFRJHwSgcb8S6UV5Sl/M10P+0NhN2Awz0ZrBHDVqIdN+6adwbZZssnGenh7hgizc DkpYDl95CO1wCI3Xaay8XOOMqDVVpj0= 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=RJpdT2TuLX3rRzXEHlG8PsweP6fxFNpA/3TiJp72Sck=; b=EyNymHEPUnKYceBO6ggRNe0dHk SRAjEmv1T0PLwVNYmgMS60Wyu2dVgl5IAQAkhoP0RF4cXv+yk3KGFvARoXCaJG9rxr2gDazAolFC5 T1USF2yfPy2/5CX9R2MUeBYgYcyfM1dqeZkcryawIY5HdFurvfMWp5z0EBR8PzXBAhAYLE0Nd1ETz 0bTUzNCOxa/Kc+rWXVkvoJVPZ7V3kboycx+ZfU/xAwQTKXlYpv6e+1nywDB/8ozyIfVaJ7AwNd7xe Yqe7Kv/csfiF8A1hf/c2s79i0npK20cbzmgxPaQLZrxWpSUF+EokHACH8uhH05wJ3zVxGS6PQeOf/ cucPPK4w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qWiFg-004uCD-0q; Thu, 17 Aug 2023 19:01:48 +0000 Date: Thu, 17 Aug 2023 20:01:47 +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-Rspam-User: X-Stat-Signature: m5tpziqeycn93chzr9wwrbpqftrfm75t X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 634524004B X-HE-Tag: 1692298913-631722 X-HE-Meta: U2FsdGVkX18G2fPQhBPlnPAiZ3zAiiRk1Ta9UfO7IJ6Kn7j+GHl3UHzBm+mKd/RpAoW2eQynqUxpmXpUleg/ak+daLJekCCh1TflQYvAhUUrrQXKzaYUlWGfYGAKRm0+wgL12UGWd9zbxugfS9sFiqe1T4C+XBaeinhQ/a+TBHZxQtKww892MSt9VWXEapBEuuwF9fOTj8QXUyEj2BLu4bMESRRRzHP5QAwTYf+jguLsqtVFkHxBlsh8LdcH581zrHiRq/UqCgfD8ec26m0izFdssBIu8epqg/pAtl7BJa3QrQrpVoVv94yIDqtTVoOC4zY0Mg7Bxu5xMAk/REnOzAZ3n0IZdLZo6KgClFYhSuXEKbax9mOH1oEu7pnXD4phs2RTkMqWd0teS0yJf6+oTTq6i2PT72x7y6tZ3v5ONWeDloKhobQx/pEw1YVlxnZKcROVbr436/WzGewWv4ZlUc0FBcFB/6L54ICMhXloGBs0mrEXQ25pcmAmMOp2yHSx5hrxFdjGe2ZRKp07yjWeXNvxZ8AuSmyN43Lm8NH/UbUmboPgeIlVrDaPPyArN2r5grv51nBxa8UZbUPPnd+fDtpDxwBk2ZKaHsyLIAUUCgoNvJAieOVWeRyEZIIG+YggCPzqxQ3hUA2VuNLyS2EDLUROaqeXtlcpUmTk4SdXp9IqxCMhgwBXZN4axq2emBw15BtWRKcR9MedIIILrokjI9kvD1oZadiRmXfynt/3n4VUOhm+1KbhlZYqDah2DBKZbIj0VDuQ4WG5aWTw5P+xRomMSQ5RFRB1kMAUiWyXcqHGPPdSTou1Lxxj8WiFv2fqdnTXsl6nQLurdi3IbP7YHF81ay/51sfUAWrTk+E+5GnyuQvrKhJQbqNr0rq3hgATcbYhFYReChuakeRBbH89Grstxbp84ode6+u3aHCmfM7zveH/sKcsu8xlq0lVZRZEEQSCSJ5Jn4A8UVFjazt PzoeZuQb RKkOA30tCrAqnTCmqnoRT8ImhJKAhLFu38MeNgNJz4jNOvT5LvLdTkZrPMrdMEAbdszuwehm4YvxNe3Pz8H34ZMevEUGxwXkALm/EULyqc2LVmkayJ2P3QnV3JwMoa/V5R5DMDft67/UsEAmS7aZKUv4HSDJx3OHHtLywRoT0FsKQSJkhOb12q+bxhClo0JLXierSZ8YH13cfsaSScWSEWiynYixZbuaWE8Mb 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 Thu, Aug 17, 2023 at 11:13:36AM -0700, Zach O'Keefe wrote: > > > IIUC then, there is a bug in smaps THPeligible code when > > > CONFIG_READ_ONLY_THP_FOR_FS is not set. Not obvious, but apparently > > > this config is (according to it's Kconfig desc) khugepaged-only, so it > > > should be fine for it to be disabled, yet allow > > > do_sync_mmap_readahead() to install a pmd for file-backed memory. > > > hugepage_vma_check() will need to be patched to fix this. > > > > I guess so ... > > The easiest and most satisfying way to handle this -- and I think we > talked about this before -- is relaxing that complicated > file_thp_enabled() check when the file's mapping supports large > folios. I think that makes sense to me, though I don't know all the > details fs-side. Will we need any hook to give fs the chance to update > any internal state on collapse? If the filesystem has per-folio metadata, we need to give the filesystem the chance to set that up. I've vaguaely been wondering about using the ->migrate_folio callback for it. At the moment, I think it just refuses to work if the folio isn't order-0. > > > But I have a larger question for you: should we care about > > > /sys/kernel/mm/transparent_hugepage/enabled for file-fault? We > > > currently don't. Seems weird that we can transparently get a hugepage > > > when THP="never". Also, if THP="always", we might as well skip the > > > VM_HUGEPAGE check, and try the final pmd install (and save khugepaged > > > the trouble of attempting it later). > > > > I deliberately ignored the humungous complexity of the THP options. > > They're overgrown and make my brain hurt. [..] > > Same > > > [..] Instead, large folios are > > adaptive; they observe the behaviour of the user program and choose based > > on history what to do. This is far superior to having a sysadmin tell > > us what to do! > > I had written a bunch on this, but I arrived to the conclusion that > (a) pmd-mapping here is ~ a free win, and (b) I'm not the best person > to argue for these knobs, given MADV_COLLAPSE ignores them entirely :P > > ..But (sorry) what about MMF_DISABLE_THP? Yeah, we ignore that too. My rationale is -- as you said -- using the PMDs is actually free, and it's really none of the app's business how the page cache chooses to cache things.