From: Oscar Salvador <osalvador@suse.de> To: Andrew Morton <akpm@linux-foundation.org> Cc: David Hildenbrand <david@redhat.com>, Michal Hocko <mhocko@kernel.org>, Anshuman Khandual <anshuman.khandual@arm.com>, Vlastimil Babka <vbabka@suse.cz>, Pavel Tatashin <pasha.tatashin@soleen.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador <osalvador@suse.de> Subject: [PATCH RFC] mm,memory_hotplug: Drop unneeded locking Date: Fri, 28 May 2021 09:51:55 +0200 [thread overview] Message-ID: <20210528075155.358-1-osalvador@suse.de> (raw) 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
next reply other threads:[~2021-05-28 7:52 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-28 7:51 Oscar Salvador [this message] 2021-05-28 8:50 ` David Hildenbrand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210528075155.358-1-osalvador@suse.de \ --to=osalvador@suse.de \ --cc=akpm@linux-foundation.org \ --cc=anshuman.khandual@arm.com \ --cc=david@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=pasha.tatashin@soleen.com \ --cc=vbabka@suse.cz \ --subject='Re: [PATCH RFC] mm,memory_hotplug: Drop unneeded locking' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
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).