The patch titled
Subject: mm: remove managed_page_count_lock spinlock
has been added to the -mm tree. Its filename is
mm-remove-managed_page_count-spinlock.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-remove-managed_page_count-spinlock.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-remove-managed_page_count-spinlock.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Arun KS <arunks@xxxxxxxxxxxxxx>
Subject: mm: remove managed_page_count_lock spinlock
Now that totalram_pages and managed_pages are atomic varibles, no need of
managed_page_count spinlock. The lock had really a weak consistency
guarantee. It hasn't been used for anything but the update but no reader
actually cares about all the values being updated to be in sync.
Link: http://lkml.kernel.org/r/1542090790-21750-5-git-send-email-arunks@xxxxxxxxxxxxxx
Signed-off-by: Arun KS <arunks@xxxxxxxxxxxxxx>
Reviewed-by: Konstantin Khlebnikov <khlebnikov@xxxxxxxxxxxxxx>
Acked-by: Michal Hocko <mhocko@xxxxxxxx>
Acked-by: Vlastimil Babka <vbabka@xxxxxxx>
Cc: David Hildenbrand <david@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
include/linux/mmzone.h | 6 ------
mm/page_alloc.c | 5 -----
2 files changed, 11 deletions(-)
--- a/include/linux/mmzone.h~mm-remove-managed_page_count-spinlock
+++ a/include/linux/mmzone.h
@@ -428,12 +428,6 @@ struct zone {
* Write access to present_pages at runtime should be protected by
* mem_hotplug_begin/end(). Any reader who can't tolerant drift of
* present_pages should get_online_mems() to get a stable value.
- *
- * Read access to managed_pages should be safe because it's unsigned
- * long. Write access to zone->managed_pages and totalram_pages are
- * protected by managed_page_count_lock at runtime. Idealy only
- * adjust_managed_page_count() should be used instead of directly
- * touching zone->managed_pages and totalram_pages.
*/
atomic_long_t managed_pages;
unsigned long spanned_pages;
--- a/mm/page_alloc.c~mm-remove-managed_page_count-spinlock
+++ a/mm/page_alloc.c
@@ -122,9 +122,6 @@ nodemask_t node_states[NR_NODE_STATES] _
};
EXPORT_SYMBOL(node_states);
-/* Protect totalram_pages and zone->managed_pages */
-static DEFINE_SPINLOCK(managed_page_count_lock);
-
atomic_long_t _totalram_pages __read_mostly;
EXPORT_SYMBOL(_totalram_pages);
unsigned long totalreserve_pages __read_mostly;
@@ -7186,14 +7183,12 @@ early_param("movablecore", cmdline_parse
void adjust_managed_page_count(struct page *page, long count)
{
- spin_lock(&managed_page_count_lock);
atomic_long_add(count, &page_zone(page)->managed_pages);
totalram_pages_add(count);
#ifdef CONFIG_HIGHMEM
if (PageHighMem(page))
totalhigh_pages_add(count);
#endif
- spin_unlock(&managed_page_count_lock);
}
EXPORT_SYMBOL(adjust_managed_page_count);
_
Patches currently in -mm which might be from arunks@xxxxxxxxxxxxxx are
mm-reference-totalram_pages-and-managed_pages-once-per-function.patch
mm-convert-zone-managed_pages-to-atomic-variable.patch
mm-convert-totalram_pages-and-totalhigh_pages-variables-to-atomic.patch
mm-remove-managed_page_count-spinlock.patch
memory_hotplug-free-pages-as-higher-order.patch
mm-page_alloc-remove-software-prefetching-in-__free_pages_core.patch
