linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC] mm,memory_hotplug: Drop unneeded locking
@ 2021-05-28  7:51 Oscar Salvador
  2021-05-28  8:50 ` David Hildenbrand
  0 siblings, 1 reply; 2+ messages in thread
From: Oscar Salvador @ 2021-05-28  7:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Hildenbrand, Michal Hocko, Anshuman Khandual,
	Vlastimil Babka, Pavel Tatashin, linux-mm, linux-kernel,
	Oscar Salvador

Currently, memory-hotplug code takes zone's span_writelock
and pgdat's resize_lock when resizing the node/zone's spanned
pages via {move_pfn_range_to_zone(),remove_pfn_range_from_zone()}
and when resizing node and zone's present pages via
adjust_present_page_count().

These locks are also taken during the initialization of the system
at boot time, where it protects parallel struct page initialization,
but they should not really be needed in memory-hotplug where all
operations are a) synchronized on device level and b) serialized by
the mem_hotplug_lock lock.

Signed-off-by: Oscar Salvador <osalvador@suse.de>
---
During the review of [1], it was brought up that we might need to revisit
the locking scheme in memory-hotplug code wrt. node and zone locks.
Given that memory-hotplug is serialized and synchronized by memory-hotplug lock
and the device, I do not think we need to hold zone/node's resize lock anymore.
After the system has been brought up, memory-hotplug is the only code allow to
touch {spanned,present}_pages, so it cannot really go off when serialized by its
own lock. Or am I missing something?
The only think I am not really sure is: if the from remove_pfn_range_from_zone,
shrink_zone_span, update_pgdat_span and move_pfn_range_to_zone can really go
(because those functions are already serialized by the memory-hotplug lock),
what about mhp_(de)init_memmap_on_memory that calls those functions?
Those are not protected by the lock. I have to confess that when it comes to locking
in this code, I always have to scratch my head.

[1] https://patchwork.kernel.org/project/linux-mm/patch/20210416112411.9826-4-osalvador@suse.de/

 mm/memory_hotplug.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 075b34803fec..6edd7e267cad 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -329,7 +329,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
 	unsigned long pfn;
 	int nid = zone_to_nid(zone);
 
-	zone_span_writelock(zone);
 	if (zone->zone_start_pfn == start_pfn) {
 		/*
 		 * If the section is smallest section in the zone, it need
@@ -362,7 +361,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
 			zone->spanned_pages = 0;
 		}
 	}
-	zone_span_writeunlock(zone);
 }
 
 static void update_pgdat_span(struct pglist_data *pgdat)
@@ -424,10 +422,8 @@ void __ref remove_pfn_range_from_zone(struct zone *zone,
 
 	clear_zone_contiguous(zone);
 
-	pgdat_resize_lock(zone->zone_pgdat, &flags);
 	shrink_zone_span(zone, start_pfn, start_pfn + nr_pages);
 	update_pgdat_span(pgdat);
-	pgdat_resize_unlock(zone->zone_pgdat, &flags);
 
 	set_zone_contiguous(zone);
 }
@@ -639,14 +635,10 @@ void __ref move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
 	clear_zone_contiguous(zone);
 
 	/* TODO Huh pgdat is irqsave while zone is not. It used to be like that before */
-	pgdat_resize_lock(pgdat, &flags);
-	zone_span_writelock(zone);
 	if (zone_is_empty(zone))
 		init_currently_empty_zone(zone, start_pfn, nr_pages);
 	resize_zone_range(zone, start_pfn, nr_pages);
-	zone_span_writeunlock(zone);
 	resize_pgdat_range(pgdat, start_pfn, nr_pages);
-	pgdat_resize_unlock(pgdat, &flags);
 
 	/*
 	 * Subsection population requires care in pfn_to_online_page().
@@ -739,9 +731,7 @@ void adjust_present_page_count(struct zone *zone, long nr_pages)
 	unsigned long flags;
 
 	zone->present_pages += nr_pages;
-	pgdat_resize_lock(zone->zone_pgdat, &flags);
 	zone->zone_pgdat->node_present_pages += nr_pages;
-	pgdat_resize_unlock(zone->zone_pgdat, &flags);
 }
 
 int mhp_init_memmap_on_memory(unsigned long pfn, unsigned long nr_pages,
-- 
2.16.3


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH RFC] mm,memory_hotplug: Drop unneeded locking
  2021-05-28  7:51 [PATCH RFC] mm,memory_hotplug: Drop unneeded locking Oscar Salvador
@ 2021-05-28  8:50 ` David Hildenbrand
  0 siblings, 0 replies; 2+ messages in thread
From: David Hildenbrand @ 2021-05-28  8:50 UTC (permalink / raw)
  To: Oscar Salvador, Andrew Morton
  Cc: Michal Hocko, Anshuman Khandual, Vlastimil Babka, Pavel Tatashin,
	linux-mm, linux-kernel

On 28.05.21 09:51, Oscar Salvador wrote:
> Currently, memory-hotplug code takes zone's span_writelock
> and pgdat's resize_lock when resizing the node/zone's spanned
> pages via {move_pfn_range_to_zone(),remove_pfn_range_from_zone()}
> and when resizing node and zone's present pages via
> adjust_present_page_count().
> 
> These locks are also taken during the initialization of the system
> at boot time, where it protects parallel struct page initialization,
> but they should not really be needed in memory-hotplug where all
> operations are a) synchronized on device level and b) serialized by
> the mem_hotplug_lock lock.
> 
> Signed-off-by: Oscar Salvador <osalvador@suse.de>
> ---
> During the review of [1], it was brought up that we might need to revisit
> the locking scheme in memory-hotplug code wrt. node and zone locks.
> Given that memory-hotplug is serialized and synchronized by memory-hotplug lock
> and the device, I do not think we need to hold zone/node's resize lock anymore.
> After the system has been brought up, memory-hotplug is the only code allow to
> touch {spanned,present}_pages, so it cannot really go off when serialized by its
> own lock. Or am I missing something?
> The only think I am not really sure is: if the from remove_pfn_range_from_zone,
> shrink_zone_span, update_pgdat_span and move_pfn_range_to_zone can really go
> (because those functions are already serialized by the memory-hotplug lock),
> what about mhp_(de)init_memmap_on_memory that calls those functions?
> Those are not protected by the lock. I have to confess that when it comes to locking
> in this code, I always have to scratch my head.
> 

Whenever onlining/offlining memory blocks we're holding the device 
hotplug lock. So memory hot(un)plug code is completely synchronized.

If necessary at some point, we could pull the memory hotplug lock 
further out. But I doubt it is necessary at this point.

AFAIK, memory hot(un)plug isn't possible while we're still initializing 
the memmap, so this should be fine.


> [1] https://patchwork.kernel.org/project/linux-mm/patch/20210416112411.9826-4-osalvador@suse.de/
> 
>   mm/memory_hotplug.c | 10 ----------
>   1 file changed, 10 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 075b34803fec..6edd7e267cad 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -329,7 +329,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
>   	unsigned long pfn;
>   	int nid = zone_to_nid(zone);
>   
> -	zone_span_writelock(zone);
>   	if (zone->zone_start_pfn == start_pfn) {
>   		/*
>   		 * If the section is smallest section in the zone, it need
> @@ -362,7 +361,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
>   			zone->spanned_pages = 0;
>   		}
>   	}
> -	zone_span_writeunlock(zone);
>   }
>   
>   static void update_pgdat_span(struct pglist_data *pgdat)
> @@ -424,10 +422,8 @@ void __ref remove_pfn_range_from_zone(struct zone *zone,
>   
>   	clear_zone_contiguous(zone);
>   
> -	pgdat_resize_lock(zone->zone_pgdat, &flags);
>   	shrink_zone_span(zone, start_pfn, start_pfn + nr_pages);
>   	update_pgdat_span(pgdat);
> -	pgdat_resize_unlock(zone->zone_pgdat, &flags);
>   
>   	set_zone_contiguous(zone);
>   }
> @@ -639,14 +635,10 @@ void __ref move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
>   	clear_zone_contiguous(zone);
>   
>   	/* TODO Huh pgdat is irqsave while zone is not. It used to be like that before */

I think you can drop this comment now as well.

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-05-28  8:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-28  7:51 [PATCH RFC] mm,memory_hotplug: Drop unneeded locking Oscar Salvador
2021-05-28  8:50 ` David Hildenbrand

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).