linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Gregory Price <gourry@gourry.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Aboorva Devarajan <aboorvad@linux.ibm.com>,
	vbabka@suse.cz, surenb@google.com, jackmanb@google.com,
	hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Oscar Salvador <OSalvador@suse.com>,
	David Hildenbrand <david@kernel.org>
Subject: Re: [PATCH] mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free
Date: Wed, 3 Dec 2025 09:42:59 +0100	[thread overview]
Message-ID: <aS_4E2H5aJmSvWF7@tiehlicka> (raw)
In-Reply-To: <aS_2Z6ROtrxLQcRN@gourry-fedora-PF4VCD3F>

On Wed 03-12-25 03:35:51, Gregory Price wrote:
> On Wed, Dec 03, 2025 at 09:27:26AM +0100, Michal Hocko wrote:
> > Let me add Oscar and David.
> > 
> > On Mon 01-12-25 09:41:12, Andrew Morton wrote:
> > > On Mon,  1 Dec 2025 11:30:09 +0530 Aboorva Devarajan <aboorvad@linux.ibm.com> wrote:
> > > 
> > > > When page isolation loops indefinitely during memory offline, reading
> > > > /proc/sys/vm/percpu_pagelist_high_fraction blocks on pcp_batch_high_lock,
> > > > causing hung task warnings.
> > > 
> > > That's pretty bad behavior.
> > > 
> > > I wonder if there are other problems which can be caused by this
> > > lengthy hold time.
> > 
> > pcp_batch_high_lock is not taken in any performance critical path. It is
> > true that memory offlining can take long when memory is not free but I
> > am not sure we can do much better. I guess we could check contention on
> > the lock and drop it to make cpu hotplug events and
> > sysctl_min_unmapped_ratio_sysctl_handler smoother. The question is
> > whether this is a practical problem hit in real life.
> > 
> 
> I just today hit a scenario where offlining was blocked on migration
> failures that took an exceedingly long time to offline (many minutes)
> even on a relatively small block (256MB).
> 
> Now that I'm looking at the double-do-while loop in memory_hotplug.c
> 
> zone_pcp_disable(zone);  /* (pcp_batch_high_lock) */
> ...
> do {
> 	do {
> ...
> 		cond_resched();
> 		ret = scan_movable_pages(pfn, end_pfn, &pfn);
> 		if (!ret) {
> 			/*
> 			 * TODO: fatal migration failures should bail
> 			 * out
> 			 */
> 			do_migrate_range(pfn, end_pfn);
> 		}
> 	} while (!ret);
> } while (ret);
> ...
> zone_pcp_enable(zone);  /* (pcp_batch_high_lock) */
> 
> 
> Maybe it's time to implement the bail out?

That would be great but can we tell transient from permanent migration
failures? Maybe long term pins could be treated as permanent failure.

> 
> ~Gregory

-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2025-12-03  8:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-01  6:00 Aboorva Devarajan
2025-12-01 17:41 ` Andrew Morton
2025-12-03  8:27   ` Michal Hocko
2025-12-03  8:35     ` Gregory Price
2025-12-03  8:42       ` Michal Hocko [this message]
2025-12-03  8:51         ` David Hildenbrand (Red Hat)
2025-12-03  9:02           ` Gregory Price
2025-12-03  9:08             ` David Hildenbrand (Red Hat)
2025-12-03  9:23               ` Gregory Price
2025-12-03  9:26                 ` Gregory Price
2025-12-03 11:28                 ` David Hildenbrand (Red Hat)
2025-12-03  8:59         ` Gregory Price
2025-12-03  9:15           ` David Hildenbrand (Red Hat)
2025-12-03  9:42             ` Michal Hocko
2025-12-03 11:22               ` David Hildenbrand (Red Hat)
2025-12-03  8:21 ` Michal Hocko

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=aS_4E2H5aJmSvWF7@tiehlicka \
    --to=mhocko@suse.com \
    --cc=OSalvador@suse.com \
    --cc=aboorvad@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=jackmanb@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=ziy@nvidia.com \
    /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