linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  reply	other threads:[~2021-06-04  7:41 UTC|newest]

Thread overview: 19+ 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-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 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).