[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f419d19-c83d-bbcd-8936-2d64ced7464c@google.com>
Date: Mon, 7 Mar 2022 18:36:42 -0800 (PST)
From: Hugh Dickins <hughd@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
cc: Yang Shi <shy828301@...il.com>,
David Hildenbrand <david@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Hugh Dickins <hughd@...gle.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
Matthew Wilcox <willy@...radead.org>,
Naresh Kamboju <naresh.kamboju@...aro.org>
Subject: Re: [PATCH] mm: thp: don't have to lock page anymore when splitting
PMD
On Mon, 7 Mar 2022, Andrew Morton wrote:
>
> OK, looks sane. Can someone please test all this?
Only the briefest of testing, but
mmotm 2022-03-06-20-33
minus mm-thp-dont-have-to-lock-page-anymore-when-splitting-pmd.patch
plus mm-huge_memory-remove-stale-locking-logic-from-__split_huge_pmd.patch
plus mm-huge_memory-remove-stale-locking-logic-from-__split_huge_pmd-fix.patch
is infinitely better than mmotm 2022-03-06-20-33.
I could just about reach a login on yesterday's mmotm, but graphics no.
Couldn't spend time to investigate, but Naresh's mail today that LTP
thp04 timeouted (hey, I'm English, we say timed out!) inspired me to
try booting with transparent_hugepage=never on cmdline, and that worked.
Again, no time to investigate, but the combination above has booted
and is running load, including transparent hugepages. And before
setting that load going, I did try LTP thp04, which passed.
(There is an unrelated console printk lockdep spew, and am I the only
one to see these mm/workingset.c:567 shadow_lru_isolate warnings that
started up a week or three ago?)
Must dash,
Hugh
Powered by blists - more mailing lists