[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YmmuivdOWcr46oNC@casper.infradead.org>
Date: Wed, 27 Apr 2022 21:58:50 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Yang Shi <shy828301@...il.com>
Cc: Vlastimil Babka <vbabka@...e.cz>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Miaohe Lin <linmiaohe@...wei.com>,
Song Liu <songliubraving@...com>,
Rik van Riel <riel@...riel.com>, Zi Yan <ziy@...dia.com>,
Theodore Ts'o <tytso@....edu>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux MM <linux-mm@...ck.org>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [v3 PATCH 0/8] Make khugepaged collapse readonly FS THP more
consistent
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.
Powered by blists - more mailing lists