linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] mm/page_alloc: fix deadlock on cpu_hotplug_lock in __accept_page()
       [not found] <20250329171030.3942298-1-kirill.shutemov@linux.intel.com>
@ 2025-03-31 19:07 ` Dave Hansen
  2025-04-01  7:25   ` Kirill A. Shutemov
  0 siblings, 1 reply; 2+ messages in thread
From: Dave Hansen @ 2025-03-31 19:07 UTC (permalink / raw)
  To: Kirill A. Shutemov, Andrew Morton
  Cc: Mike Rapoport, David Hildenbrand, Vlastimil Babka, Mel Gorman,
	Tom Lendacky, Kalra, Ashish, Rick Edgecombe, linux-mm,
	linux-coco, linux-kernel, Srikanth Aithal

On 3/29/25 10:10, Kirill A. Shutemov wrote:
> +		if (system_wq)
> +			schedule_work(&zone->unaccepted_cleanup);
> +		else
> +			unaccepted_cleanup_work(&zone->unaccepted_cleanup);
> +	}
>  }

The 'system_wq' check seems like an awfully big hack. No other
schedule_work() user does anything similar that I can find across the tree.

Instead of hacking in some internal state, could you use 'system_state',
like:

	if (system_state == SYSTEM_BOOTING)
		unaccepted_cleanup_work(&zone->unaccepted_cleanup);
	else
		schedule_work(&zone->unaccepted_cleanup);

The other method would be to make it more opportunistic? Basically,
detect when it might deadlock:

bool try_to_dec()
{
	if (!cpus_read_trylock())
		return false;

	static_branch_dec_cpuslocked(&zones_with_unaccepted_pages);
	cpus_read_unlock();

	return true;
}

That still requires a bit in the zone to say whether the
static_branch_dec() was deferred or not, though. It's kinda open-coding
schedule_work().


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] mm/page_alloc: fix deadlock on cpu_hotplug_lock in __accept_page()
  2025-03-31 19:07 ` [PATCH] mm/page_alloc: fix deadlock on cpu_hotplug_lock in __accept_page() Dave Hansen
@ 2025-04-01  7:25   ` Kirill A. Shutemov
  0 siblings, 0 replies; 2+ messages in thread
From: Kirill A. Shutemov @ 2025-04-01  7:25 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Andrew Morton, Mike Rapoport, David Hildenbrand, Vlastimil Babka,
	Mel Gorman, Tom Lendacky, Kalra, Ashish, Rick Edgecombe,
	linux-mm, linux-coco, linux-kernel, Srikanth Aithal

On Mon, Mar 31, 2025 at 12:07:07PM -0700, Dave Hansen wrote:
> On 3/29/25 10:10, Kirill A. Shutemov wrote:
> > +		if (system_wq)
> > +			schedule_work(&zone->unaccepted_cleanup);
> > +		else
> > +			unaccepted_cleanup_work(&zone->unaccepted_cleanup);
> > +	}
> >  }
> 
> The 'system_wq' check seems like an awfully big hack. No other
> schedule_work() user does anything similar that I can find across the tree.

I don't see how it is "an awfully big hack". It is "use system_wq if it is
ready".

Maybe it is going to be marginally cleaner if schedule_work() would be
open-coded:

		if (system_wq)
		        queue_work(system_wq, &zone->unaccepted_cleanup);
		else
			unaccepted_cleanup_work(&zone->unaccepted_cleanup);

?

> 
> Instead of hacking in some internal state, could you use 'system_state',
> like:
> 
> 	if (system_state == SYSTEM_BOOTING)
> 		unaccepted_cleanup_work(&zone->unaccepted_cleanup);
> 	else
> 		schedule_work(&zone->unaccepted_cleanup);

Really? The transition points between these states are arbitrary defined.
Who said that if we are out of SYSTEM_BOOTING we can use system_wq?
Tomorrow we can introduce additional state between BOOTING and SCHEDULING
and this code will be silently broken. The same for any new state before
BOOTING.

> The other method would be to make it more opportunistic? Basically,
> detect when it might deadlock:
> 
> bool try_to_dec()
> {
> 	if (!cpus_read_trylock())
> 		return false;
> 
> 	static_branch_dec_cpuslocked(&zones_with_unaccepted_pages);
> 	cpus_read_unlock();
> 
> 	return true;
> }
> 
> That still requires a bit in the zone to say whether the
> static_branch_dec() was deferred or not, though. It's kinda open-coding
> schedule_work().

It will also require special handling for soft CPU online/offline.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-04-01  7:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20250329171030.3942298-1-kirill.shutemov@linux.intel.com>
2025-03-31 19:07 ` [PATCH] mm/page_alloc: fix deadlock on cpu_hotplug_lock in __accept_page() Dave Hansen
2025-04-01  7:25   ` Kirill A. Shutemov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox