On Tue, Feb 09, 2016 at 01:20:12PM -0800, Andrew Morton wrote:
> On Tue, 9 Feb 2016 12:15:02 +0300 "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx> wrote:
>
> > Counts how many times we put a THP in split queue. Currently, it happens
> > on partial unmap of a THP.
>
> Why do we need this?
Rapidly growing value can indicate that an application behaves
unfriendly wrt THP: often fault in huge page and then unmap part of it.
This leads to unnecessary memory fragmentation and the application may
require tuning.
Before refcouting rework thp_split_page would indicate the same. Not so much
now as we don't split huge pages that often.
The event also can help with debugging kernel [mis-]behaviour.
> > --- a/mm/vmstat.c
> > +++ b/mm/vmstat.c
> > @@ -847,6 +847,7 @@ const char * const vmstat_text[] = {
> > "thp_collapse_alloc_failed",
> > "thp_split_page",
> > "thp_split_page_failed",
> > + "thp_deferred_split_page",
> > "thp_split_pmd",
> > "thp_zero_page_alloc",
> > "thp_zero_page_alloc_failed",
>
> Documentation/vm/transhuge.txt, please.
Updated patch is below.
> While you're in there please > check that we haven't missed anything else.
The rest of the documents is up-to-date.
>From 949c3f5c2aea1dc366cce4470ed7416331460eca Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
Date: Tue, 9 Feb 2016 12:10:30 +0300
Subject: [PATCH] thp, vmstats: count deferred split events
Counts how many times we put a THP in split queue. Currently, it happens
on partial unmap of a THP.
Rapidly growing value can indicate that an application behaves
unfriendly wrt THP: often fault in huge page and then unmap part of it.
This leads to unnecessary memory fragmentation and the application may
require tuning.
The event also can help with debugging kernel [mis-]behaviour.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
---
Documentation/vm/transhuge.txt | 5 +++++
include/linux/vm_event_item.h | 1 +
mm/huge_memory.c | 1 +
mm/vmstat.c | 1 +
4 files changed, 8 insertions(+)
diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 21cf34f3ddb2..0dc8632aa01e 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -229,6 +229,11 @@ thp_split_page is incremented every time a huge page is split into base
thp_split_page_failed is is incremented if kernel fails to split huge
page. This can happen if the page was pinned by somebody.
+thp_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.
+
thp_split_pmd is incremented every time a PMD split into table of PTEs.
This can happen, for instance, when application calls mprotect() or
munmap() on part of huge page. It doesn't split huge page, only
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 67c1dbd19c6d..b79e831006b0 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -71,6 +71,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
THP_COLLAPSE_ALLOC_FAILED,
THP_SPLIT_PAGE,
THP_SPLIT_PAGE_FAILED,
+ THP_DEFERRED_SPLIT_PAGE,
THP_SPLIT_PMD,
THP_ZERO_PAGE_ALLOC,
THP_ZERO_PAGE_ALLOC_FAILED,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 08fc0ba2207e..a75081ca31cf 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3458,6 +3458,7 @@ void deferred_split_huge_page(struct page *page)
spin_lock_irqsave(&pgdata->split_queue_lock, flags);
if (list_empty(page_deferred_list(page))) {
+ count_vm_event(THP_DEFERRED_SPLIT_PAGE);
list_add_tail(page_deferred_list(page), &pgdata->split_queue);
pgdata->split_queue_len++;
}
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 084c6725b373..6598c951278e 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -847,6 +847,7 @@ const char * const vmstat_text[] = {
"thp_collapse_alloc_failed",
"thp_split_page",
"thp_split_page_failed",
+ "thp_deferred_split_page",
"thp_split_pmd",
"thp_zero_page_alloc",
"thp_zero_page_alloc_failed",
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>