From: Oscar Salvador <osalvador@suse.de>
To: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
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
Subject: Re: [PATCH v2 1/3] mm,page_alloc: Use {get,put}_online_mems() to get stable zone's values
Date: Fri, 4 Jun 2021 09:41:45 +0200 [thread overview]
Message-ID: <20210604074140.GA25063@linux> (raw)
In-Reply-To: <YLjO2YU2G5fTVB3x@dhcp22.suse.cz>
On Thu, Jun 03, 2021 at 02:45:13PM +0200, Michal Hocko wrote:
> I believe we need to define the purpose of the locking first. The
If you ask me, this locking would be meant to make sure zone's zone_start_pfn
or spanned_pages do not change under us, in case we __need__ the value to be
stable.
> existing locking doesn't serve much purpose, does it? The state might
Well, half-way. Currently, the locking is taken in write mode whenever
the zone is expanded or shrinked, and in read mode when called from
bad_range()->page_outside_zone_boundaries() (only on VM_DEBUG).
But as you pointed out, such state might change right after the locking is
released and all the work would be for nothing.
So indeed, the __whole__ operation should be envolved by the lock in the caller
The way that stands right now is not optimal.
> change right after the lock is released and the caller cannot really
> rely on the result. So aside of the current implementation, I would
> argue that any locking has to be be done on the caller layer.
>
> But the primary question is whether anybody actually cares about
> potential races in the first place.
I have been checking move_freepages_block() and alloc_contig_pages(), which
are two of the functions that call zone_spans_pfn().
move_freepages_block() uses it in a way to align the given pfn to pageblock
top and bottom, and then check that aligned pfns are still within the same zone.
From a memory-hotplug perspective that's ok as we know that we are offlining
PAGES_PER_SECTION (which implies whole pageblocks).
alloc_contig_pages() (used by the hugetlb gigantic allocator) runs through a
node's zonelist and checks whether zone->zone_start_pfn + nr_pages stays within
the same zone.
IMHO, the race with zone_spans_last_pfn() vs mem-hotplug would not be that bad,
as it will be caught afters by e.g: __alloc_contig_pages when pages cannot be
isolated because they are offline etc.
So, I would say we do not really need the lock, but I might be missing something.
But if we chose to care about this, then the locking should be done right, not
half-way as it is right now.
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2021-06-04 7:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 9:14 [PATCH v2 0/3] Memory hotplug locking cleanup Oscar Salvador
2021-06-02 9:14 ` [PATCH v2 1/3] mm,page_alloc: Use {get,put}_online_mems() to get stable zone's values Oscar Salvador
2021-06-02 18:37 ` David Hildenbrand
2021-06-02 19:45 ` Oscar Salvador
2021-06-03 8:38 ` Oscar Salvador
2021-06-03 12:45 ` Michal Hocko
2021-06-04 7:41 ` Oscar Salvador [this message]
2021-06-07 7:52 ` Oscar Salvador
2021-06-07 8:49 ` David Hildenbrand
2021-06-07 10:23 ` Oscar Salvador
2021-06-08 10:42 ` Oscar Salvador
2021-06-08 15:00 ` David Hildenbrand
2021-06-09 9:42 ` David Hildenbrand
2021-06-07 8:42 ` Michal Hocko
2021-06-03 2:32 ` [mm, page_alloc] [confidence: ] acb5758bf4: BUG:sleeping_function_called_from_invalid_context_at_include/linux/percpu-rwsem.h kernel test robot
2021-06-03 2:32 ` [mm,page_alloc] " kernel test robot
2021-06-02 9:14 ` [PATCH v2 2/3] mm,memory_hotplug: Drop unneeded locking Oscar Salvador
2021-06-03 12:52 ` Michal Hocko
2021-06-02 9:14 ` [PATCH v2 3/3] mm,memory_hotplug: Remove unneeded declarations Oscar Salvador
2021-06-02 18:38 ` 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=20210604074140.GA25063@linux \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=dave.hansen@linux.intel.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.