From: Ryan Roberts <ryan.roberts@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Yin Fengwei <fengwei.yin@intel.com>,
David Hildenbrand <david@redhat.com>, Yu Zhao <yuzhao@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Yang Shi <shy828301@gmail.com>,
"Huang, Ying" <ying.huang@intel.com>, Zi Yan <ziy@nvidia.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Itaru Kitayama <itaru.kitayama@gmail.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
John Hubbard <jhubbard@nvidia.com>,
David Rientjes <rientjes@google.com>,
Vlastimil Babka <vbabka@suse.cz>, Hugh Dickins <hughd@google.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Barry Song <21cnbao@gmail.com>,
Alistair Popple <apopple@nvidia.com>,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 00/10] Multi-size THP for anonymous memory
Date: Tue, 5 Dec 2023 09:34:23 +0000 [thread overview]
Message-ID: <2de0617e-d1d7-49ec-9cb8-206eaf37caed@arm.com> (raw)
In-Reply-To: <20231204113039.42510c23455026e40c5e2a56@linux-foundation.org>
On 04/12/2023 19:30, Andrew Morton wrote:
> On Mon, 4 Dec 2023 10:20:17 +0000 Ryan Roberts <ryan.roberts@arm.com> wrote:
>
>> Hi All,
>>
>>
>> Prerequisites
>> =============
>>
>> Some work items identified as being prerequisites are listed on page 3 at [9].
>> The summary is:
>>
>> | item | status |
>> |:------------------------------|:------------------------|
>> | mlock | In mainline (v6.7) |
>> | madvise | In mainline (v6.6) |
>> | compaction | v1 posted [10] |
>> | numa balancing | Investigated: see below |
>> | user-triggered page migration | In mainline (v6.7) |
>> | khugepaged collapse | In mainline (NOP) |
>
> What does "prerequisites" mean here? Won't compile without? Kernel
> crashes without? Nice-to-have-after? Please expand on this.
Short answer: It's supposed to mean things that either need to be done to prevent the mm from regressing (both correctness and performance) when multi-size THP is present but disabled, or things that need to be done to make the mm robust (but not neccessarily optimially performant) when multi-size THP is enabled. But in reality, all of the things on the list could really be reclassified as "nice-to-have-after", IMHO; their absence will neither cause compilation nor runtime errors.
Longer answer: When I first started looking at this, I was advised that there were likely a number of corners which made assumptions about large folios always being PMD-sized, and if not found and fixed, could lead to stability issues. At the time I was also pursuing a strategy of multi-size THP being a compile-time feature with no runtime control, so I decided it was important for multi-size THP to not effectively disable other features (e.g. various madvise ops used to ignore PTE-mapped large folios). This list represents all the things that I could find based on code review, as well as things suggested by others, and in the end, they all fall into that last category of "PTE-mapped large folios efectively disable existing features". But given we now have runtime controls to opt-in to multi-size THP, I'm not sure we need to classify these as prerequisites. But I didn't want to unilaterally make that decision, given this list has previously been discussed and agreed by others.
It's also worth noting that in the case of compaction, that's already a problem for large folios in the page cache; large folios will be skipped.
>
> I looked at [9], but access is denied.
Sorry about that; its owned by David Rientjes so I can't fix that for you. It's a PDF of a slide with the following table:
+-------------------------------+------------------------------------------------------------------------+--------------+--------------------+
| Item | Description | Assignee | Status |
+-------------------------------+------------------------------------------------------------------------+--------------+--------------------+
| mlock | Large, pte-mapped folios are ignored when mlock is requested. | Yin, Fengwei | In mainline (v6.7) |
| | Code comment for mlock_vma_folio() says "...filter out pte mappings | | |
| | of THPs which cannot be consistently counted: a pte mapping of the | | |
| | THP head cannot be distinguished by the page alone." | | |
| madvise | MADV_COLD, MADV_PAGEOUT, MADV_FREE: For large folios, code assumes | Yin, Fengwei | In mainline (v6.6) |
| | exclusive only if mapcount==1, else skips remainder of operation. | | |
| | For large, pte-mapped folios, exclusive folios can have mapcount | | |
| | upto nr_pages and still be exclusive. Even better; don't split | | |
| | the folio if it fits entirely within the range. | | |
| compaction | Raised at LSFMM: Compaction skips non-order-0 pages. | Zi Yan | v1 posted |
| | Already problem for page-cache pages today. | | |
| numa balancing | Large, pte-mapped folios are ignored by numa-balancing code. Commit | John Hubbard | Investigated: |
| | comment (e81c480): "We're going to have THP mapped with PTEs. It | | Not prerequisite |
| | will confuse numabalancing. Let's skip them for now." | | |
| user-triggered page migration | mm/migrate.c (migrate_pages syscall) We don't want to migrate folio | Kefeng Wang | In mainline (v6.7) |
| | that is shared. | | |
| khugepaged collapse | collapse small-sized THP to PMD-sized THP in khugepaged/MADV_COLLAPSE. | Ryan Roberts | In mainline (NOP) |
| | Kirill thinks khugepage should already be able to collapse | | |
| | small large folios to PMD-sized THP; verification required. | | |
+-------------------------------+------------------------------------------------------------------------+--------------+--------------------+
Thanks,
Ryan
>
>> [9] https://drive.google.com/file/d/1GnfYFpr7_c1kA41liRUW5YtCb8Cj18Ud/view?usp=sharing&resourcekey=0-U1Mj3-RhLD1JV6EThpyPyA
>
>
next prev parent reply other threads:[~2023-12-05 9:34 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 10:20 [PATCH v8 00/10] Multi-size THP for anonymous memory Ryan Roberts
2023-12-04 10:20 ` [PATCH v8 01/10] mm: Allow deferred splitting of arbitrary anon large folios Ryan Roberts
2023-12-04 10:20 ` [PATCH v8 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap() Ryan Roberts
2023-12-05 0:58 ` Barry Song
2023-12-04 10:20 ` [PATCH v8 03/10] mm: thp: Introduce multi-size THP sysfs interface Ryan Roberts
2023-12-05 4:21 ` Barry Song
2023-12-05 9:50 ` Ryan Roberts
2023-12-05 9:57 ` David Hildenbrand
2023-12-05 10:50 ` Ryan Roberts
2023-12-05 16:57 ` David Hildenbrand
2023-12-06 13:18 ` Ryan Roberts
2023-12-07 10:56 ` Ryan Roberts
2023-12-07 11:13 ` David Hildenbrand
2023-12-07 11:22 ` Ryan Roberts
2023-12-07 11:25 ` David Hildenbrand
2023-12-07 11:44 ` Ryan Roberts
2023-12-04 10:20 ` [PATCH v8 04/10] mm: thp: Support allocation of anonymous multi-size THP Ryan Roberts
2023-12-05 1:15 ` Barry Song
2023-12-05 1:24 ` Barry Song
2023-12-05 10:48 ` Ryan Roberts
2023-12-05 11:16 ` David Hildenbrand
2023-12-05 20:16 ` Barry Song
2023-12-06 10:15 ` Ryan Roberts
2023-12-06 10:25 ` Barry Song
2023-12-05 16:32 ` David Hildenbrand
2023-12-05 16:35 ` David Hildenbrand
2023-12-06 14:19 ` Ryan Roberts
2023-12-06 15:44 ` Ryan Roberts
2023-12-07 10:37 ` Ryan Roberts
2023-12-07 10:40 ` David Hildenbrand
2023-12-07 11:08 ` David Hildenbrand
2023-12-07 12:08 ` Ryan Roberts
2023-12-07 13:28 ` David Hildenbrand
2023-12-07 14:45 ` Ryan Roberts
2023-12-07 15:01 ` David Hildenbrand
2023-12-07 15:12 ` Ryan Roberts
2023-12-04 10:20 ` [PATCH v8 05/10] selftests/mm/kugepaged: Restore thp settings at exit Ryan Roberts
2023-12-05 17:00 ` David Hildenbrand
2023-12-04 10:20 ` [PATCH v8 06/10] selftests/mm: Factor out thp settings management Ryan Roberts
2023-12-05 17:03 ` David Hildenbrand
2023-12-04 10:20 ` [PATCH v8 07/10] selftests/mm: Support multi-size THP interface in thp_settings Ryan Roberts
2023-12-04 10:20 ` [PATCH v8 08/10] selftests/mm/khugepaged: Enlighten for multi-size THP Ryan Roberts
2023-12-04 10:20 ` [PATCH v8 09/10] selftests/mm/cow: Generalize do_run_with_thp() helper Ryan Roberts
2023-12-05 9:59 ` David Hildenbrand
2023-12-04 10:20 ` [PATCH v8 10/10] selftests/mm/cow: Add tests for anonymous multi-size THP Ryan Roberts
2023-12-05 16:00 ` David Hildenbrand
2023-12-04 19:30 ` [PATCH v8 00/10] Multi-size THP for anonymous memory Andrew Morton
2023-12-05 9:34 ` Ryan Roberts [this message]
2023-12-05 3:28 ` Barry Song
2023-12-05 11:05 ` Ryan Roberts
2023-12-05 3:37 ` John Hubbard
2023-12-05 11:13 ` Ryan Roberts
2023-12-05 18:58 ` John Hubbard
2023-12-05 14:19 ` Kefeng Wang
2023-12-06 10:08 ` Ryan Roberts
2023-12-07 15:50 ` Kefeng Wang
2023-12-05 17:21 ` David Hildenbrand
2023-12-06 10:13 ` Ryan Roberts
2023-12-06 10:22 ` David Hildenbrand
2023-12-06 14:22 ` Ryan Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2de0617e-d1d7-49ec-9cb8-206eaf37caed@arm.com \
--to=ryan.roberts@arm.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=apopple@nvidia.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=fengwei.yin@intel.com \
--cc=hughd@google.com \
--cc=itaru.kitayama@gmail.com \
--cc=jhubbard@nvidia.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=rientjes@google.com \
--cc=shy828301@gmail.com \
--cc=vbabka@suse.cz \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).