| Message ID | 20240424135148.30422-3-ioworker0@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: introduce per-order mTHP split counters | expand |
On 24/04/2024 14:51, Lance Yang wrote: > This commit introduces documentation for mTHP split counters in > transhuge.rst. > > Signed-off-by: Lance Yang <ioworker0@gmail.com> > --- > Documentation/admin-guide/mm/transhuge.rst | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst > index f82300b9193f..35d574a531c8 100644 > --- a/Documentation/admin-guide/mm/transhuge.rst > +++ b/Documentation/admin-guide/mm/transhuge.rst > @@ -475,6 +475,22 @@ anon_swpout_fallback > Usually because failed to allocate some continuous swap space > for the huge page. > > +split_page > + is incremented every time a huge page is split into base perhaps "...successfully split into base..." to make it clear that this is only incremented on success. > + pages. This can happen for a variety of reasons but a common > + reason is that a huge page is old and is being reclaimed. > + This action implies splitting all PMD/PTE mapped with the huge page. What does it mean to "split all PTE"? It's already at its smallest granularity. Perhaps "This action implies splitting any block mappings into PTEs."? > + > +split_page_failed > + is incremented if kernel fails to split huge > + page. This can happen if the page was pinned by somebody. > + > +deferred_split_page > + is incremented when a huge page is put onto split > + queue. This happens when a huge page is partially unmapped and > + splitting it would free up some memory. Pages on split queue are > + going to be split under memory pressure. > + > As the system ages, allocating huge pages may be expensive as the > system uses memory compaction to copy data around memory to free a > huge page for use. There are some counters in ``/proc/vmstat`` to help
Hey Ryan, Thanks for taking time to review! On Wed, Apr 24, 2024 at 11:34 PM Ryan Roberts <ryan.roberts@arm.com> wrote: > > On 24/04/2024 14:51, Lance Yang wrote: > > This commit introduces documentation for mTHP split counters in > > transhuge.rst. > > > > Signed-off-by: Lance Yang <ioworker0@gmail.com> > > --- > > Documentation/admin-guide/mm/transhuge.rst | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst > > index f82300b9193f..35d574a531c8 100644 > > --- a/Documentation/admin-guide/mm/transhuge.rst > > +++ b/Documentation/admin-guide/mm/transhuge.rst > > @@ -475,6 +475,22 @@ anon_swpout_fallback > > Usually because failed to allocate some continuous swap space > > for the huge page. > > > > +split_page > > + is incremented every time a huge page is split into base > > perhaps "...successfully split into base..." to make it clear that this is only > incremented on success. Yep. Your suggestion does make it clearer. > > > + pages. This can happen for a variety of reasons but a common > > + reason is that a huge page is old and is being reclaimed. > > + This action implies splitting all PMD/PTE mapped with the huge page. > > What does it mean to "split all PTE"? It's already at its smallest granularity. > Perhaps "This action implies splitting any block mappings into PTEs."? Nice. It would be clearer and better! Thanks again for the suggestions! Lance > > > + > > +split_page_failed > > + is incremented if kernel fails to split huge > > + page. This can happen if the page was pinned by somebody. > > + > > +deferred_split_page > > + is incremented when a huge page is put onto split > > + queue. This happens when a huge page is partially unmapped and > > + splitting it would free up some memory. Pages on split queue are > > + going to be split under memory pressure. > > + > > As the system ages, allocating huge pages may be expensive as the > > system uses memory compaction to copy data around memory to free a > > huge page for use. There are some counters in ``/proc/vmstat`` to help >
diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index f82300b9193f..35d574a531c8 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -475,6 +475,22 @@ anon_swpout_fallback Usually because failed to allocate some continuous swap space for the huge page. +split_page + is incremented every time a huge page is split into base + pages. This can happen for a variety of reasons but a common + reason is that a huge page is old and is being reclaimed. + This action implies splitting all PMD/PTE mapped with the huge page. + +split_page_failed + is incremented if kernel fails to split huge + page. This can happen if the page was pinned by somebody. + +deferred_split_page + is incremented when a huge page is put onto split + queue. This happens when a huge page is partially unmapped and + splitting it would free up some memory. Pages on split queue are + going to be split under memory pressure. + As the system ages, allocating huge pages may be expensive as the system uses memory compaction to copy data around memory to free a huge page for use. There are some counters in ``/proc/vmstat`` to help
This commit introduces documentation for mTHP split counters in transhuge.rst. Signed-off-by: Lance Yang <ioworker0@gmail.com> --- Documentation/admin-guide/mm/transhuge.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)