mm: introduce new field "managed_pages" to struct zone

Currently a zone's present_pages is calcuated as below, which is
inaccurate and may cause trouble to memory hotplug.

	spanned_pages - absent_pages - memmap_pages - dma_reserve.

During fixing bugs caused by inaccurate zone->present_pages, we found
zone->present_pages has been abused.  The field zone->present_pages may
have different meanings in different contexts:

1) pages existing in a zone.
2) pages managed by the buddy system.

For more discussions about the issue, please refer to:
  http://lkml.org/lkml/2012/11/5/866
  https://patchwork.kernel.org/patch/1346751/

This patchset tries to introduce a new field named "managed_pages" to
struct zone, which counts "pages managed by the buddy system".  And revert
zone->present_pages to count "physical pages existing in a zone", which
also keep in consistence with pgdat->node_present_pages.

We will set an initial value for zone->managed_pages in function
free_area_init_core() and will adjust it later if the initial value is
inaccurate.

For DMA/normal zones, the initial value is set to:

	(spanned_pages - absent_pages - memmap_pages - dma_reserve)

Later zone->managed_pages will be adjusted to the accurate value when the
bootmem allocator frees all free pages to the buddy system in function
free_all_bootmem_node() and free_all_bootmem().

The bootmem allocator doesn't touch highmem pages, so highmem zones'
managed_pages is set to the accurate value "spanned_pages - absent_pages"
in function free_area_init_core() and won't be updated anymore.

This patch also adds a new field "managed_pages" to /proc/zoneinfo
and sysrq showmem.

[akpm@linux-foundation.org: small comment tweaks]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Cc: "Rafael J . Wysocki" <rjw@sisk.pl>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan@kernel.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Jianguo Wu <wujianguo@huawei.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

1 files changed, 34 insertions, 7 deletions

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0c0b1d608a69..cd55dad56aac 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -460,17 +460,44 @@ struct zone {
         unsigned long           zone_start_pfn;
 
         /*
-         * zone_start_pfn, spanned_pages and present_pages are all
-         * protected by span_seqlock.  It is a seqlock because it has
-         * to be read outside of zone->lock, and it is done in the main
-         * allocator path.  But, it is written quite infrequently.
+         * spanned_pages is the total pages spanned by the zone, including
+         * holes, which is calculated as:
+         *      spanned_pages = zone_end_pfn - zone_start_pfn;
          *
-         * The lock is declared along with zone->lock because it is
+         * present_pages is physical pages existing within the zone, which
+         * is calculated as:
+         *      present_pages = spanned_pages - absent_pages(pags in holes);
+         *
+         * managed_pages is present pages managed by the buddy system, which
+         * is calculated as (reserved_pages includes pages allocated by the
+         * bootmem allocator):
+         *      managed_pages = present_pages - reserved_pages;
+         *
+         * So present_pages may be used by memory hotplug or memory power
+         * management logic to figure out unmanaged pages by checking
+         * (present_pages - managed_pages). And managed_pages should be used
+         * by page allocator and vm scanner to calculate all kinds of watermarks
+         * and thresholds.
+         *
+         * Locking rules:
+         *
+         * zone_start_pfn and spanned_pages are protected by span_seqlock.
+         * It is a seqlock because it has to be read outside of zone->lock,
+         * and it is done in the main allocator path.  But, it is written
+         * quite infrequently.
+         *
+         * The span_seq lock is declared along with zone->lock because it is
          * frequently read in proximity to zone->lock.  It's good to
          * give them a chance of being in the same cacheline.
+         *
+         * Write access to present_pages and managed_pages at runtime should
+         * be protected by lock_memory_hotplug()/unlock_memory_hotplug().
+         * Any reader who can't tolerant drift of present_pages and
+         * managed_pages should hold memory hotplug lock to get a stable value.
          */
-        unsigned long           spanned_pages;  /* total size, including holes */
-        unsigned long           present_pages;  /* amount of memory (excluding holes) */
+        unsigned long           spanned_pages;
+        unsigned long           present_pages;
+        unsigned long           managed_pages;
 
         /*
          * rarely used fields: