From: Oscar Salvador <osalvador@suse.de>
To: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm,memory_hotplug: Drop unneeded locking
Date: Tue, 1 Jun 2021 12:33:43 +0200 [thread overview]
Message-ID: <20210601103334.GA5927@linux> (raw)
In-Reply-To: <YLYCIZ5XNXGoE95p@dhcp22.suse.cz>
On Tue, Jun 01, 2021 at 11:47:13AM +0200, Michal Hocko wrote:
> While you are touching this and want to drill all the way down then it
> would be reasonable to drop pgdat resize locks as well.
> It is only used in the early boot code and we have one executing thread
> context per numa node during the deferred initialization. I haven't
> checked all potential side effects the lock might have but it sounds
> like there is quite some clean up potential over there.
I am not sure about that. True is that deferred_init_memmap() gets executed
on numa-thread so it's not a problem for itself, but we also have deferred_grow_zone().
It might be that while deferred_init_memmap() is running, we also have calls to
deferred_grow_zone() for the same node and that would cause some trouble wrt.
first_deferred_pfn. I need to double check it, but IIRC, that is the case.
--
Oscar Salvador
SUSE L3
prev parent reply other threads:[~2021-06-01 10:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-31 9:39 [PATCH] mm,memory_hotplug: Drop unneeded locking Oscar Salvador
2021-05-31 11:37 ` Michal Hocko
2021-06-01 5:17 ` Anshuman Khandual
2021-06-01 7:47 ` Oscar Salvador
2021-06-01 8:02 ` David Hildenbrand
2021-06-01 8:12 ` Oscar Salvador
2021-06-01 9:47 ` Michal Hocko
2021-06-01 10:33 ` Oscar Salvador [this message]
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=20210601103334.GA5927@linux \
--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@suse.com \
--cc=pasha.tatashin@soleen.com \
--cc=vbabka@suse.cz \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.