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 619F7C433F5 for ; Wed, 27 Apr 2022 20:59:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D0A116B0071; Wed, 27 Apr 2022 16:59:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB7996B0073; Wed, 27 Apr 2022 16:59:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5A156B0074; Wed, 27 Apr 2022 16:59:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id A194F6B0071 for ; Wed, 27 Apr 2022 16:59:25 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 808D9816BE for ; Wed, 27 Apr 2022 20:59:25 +0000 (UTC) X-FDA: 79403874690.10.C009FA8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 70564100059 for ; Wed, 27 Apr 2022 20:59:23 +0000 (UTC) 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=cQesnUHvsevqj8LCTS5dD+iCwEbXRZtgTgIlz/6PQHA=; b=dQ/6BATy3PF81w6PED0XHEp3gD kftx4U8C6qeWcvUH3ZKLbETVaFKpz7FcHnukq3jsRdRmXaJ3r/HcJdMVHGCtDtet9lICy7bFrw2CH 7P1R4PbKuS2+j+Hu/UXuNt6L5qEW4K640a1xv6gaizmtryGaJn5dxYM6UZu+6WkxB1T79alvJLP17 ytqPbxhBOxof5c40hsU7nvWGc2MJ/RMqKLBegO27btlO9otBrgkzXRjr1oM4NocCYa00HKxMMXUOh otBgFrlO6ytA+LZJDnD/9BidfUlhByUgAtaZ/npUnHuR6v7XK0bYK439224eqgIOHu6lLgiFau7Db Za00Ud2g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1njokM-00Atky-89; Wed, 27 Apr 2022 20:58:50 +0000 Date: Wed, 27 Apr 2022 21:58:50 +0100 From: Matthew Wilcox To: Yang Shi Cc: Vlastimil Babka , "Kirill A. Shutemov" , Miaohe Lin , Song Liu , Rik van Riel , Zi Yan , Theodore Ts'o , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Subject: Re: [v3 PATCH 0/8] Make khugepaged collapse readonly FS THP more consistent Message-ID: References: <20220404200250.321455-1-shy828301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 70564100059 X-Stat-Signature: t49a1q9sts379e7acqeey9o9hrn13n6b X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="dQ/6BATy"; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam09 X-HE-Tag: 1651093163-386709 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, Apr 04, 2022 at 05:48:49PM -0700, Yang Shi wrote: > When khugepaged collapses file THPs, its behavior is not consistent. > It is kind of "random luck" for khugepaged to see the file vmas (see > report: https://lore.kernel.org/linux-mm/00f195d4-d039-3cf2-d3a1-a2c88de397a0@suse.cz/) > since currently the vmas are registered to khugepaged when: > - Anon huge pmd page fault > - VMA merge > - MADV_HUGEPAGE > - Shmem mmap > > If the above conditions are not met, even though khugepaged is enabled > it won't see any file vma at all. MADV_HUGEPAGE could be specified > explicitly to tell khugepaged to collapse this area, but when > khugepaged mode is "always" it should scan suitable vmas as long as > VM_NOHUGEPAGE is not set. I don't see that as being true at all. The point of this hack was that applications which really knew what they were doing could enable it. It makes no sense to me that setting "always" by the sysadmin for shmem also force-enables ROTHP, even for applications which aren't aware of it. Most telling, I think, is that Song Liu hasn't weighed in on this at all. It's clearly not important to the original author.