Received-SPF: pass (google.com: domain of linux-kernel+bounces-56964-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Sender: Tejun Heo <htejun@gmail.com>
Date: Wed, 7 Feb 2024 08:58:01 -1000
From: Tejun Heo <tj@kernel.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PM <linux-pm@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Nathan Chancellor <nathan@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>, Naohiro.Aota@wdc.com,
	kernel-team@meta.com
Subject: Re: [PATCH v1] PM: sleep: Restore asynchronous device resume
 optimization
Message-ID: <ZcPSuUBoL_EDvcTF@slm.duckdns.org>
References: <CGME20240207103144eucas1p16b601a73ff347d2542f8380b25921491@eucas1p1.samsung.com>
 <10423008.nUPlyArG6x@kreacher>
 <708a65cc-79ec-44a6-8454-a93d0f3114c3@samsung.com>
 <CAJZ5v0hn=KgaWn9pwtLsH2a8n61BNxzb1xrNoxUfEi3o9OAZGw@mail.gmail.com>
 <4a043533-009f-4db9-b107-c8374be28d2b@samsung.com>
 <CAJZ5v0hDmwaFEtLc8yDc4cXn2wODXAqATe0+_Hpm9QPODUPMQw@mail.gmail.com>
 <ZcOyW_Q1FC35oxob@slm.duckdns.org>
 <2f125955-8c7c-465c-938c-8768f7ca360b@samsung.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2f125955-8c7c-465c-938c-8768f7ca360b@samsung.com>

On Wed, Feb 07, 2024 at 07:55:51PM +0100, Marek Szyprowski wrote:
> On 07.02.2024 17:39, Tejun Heo wrote:
> > On Wed, Feb 07, 2024 at 12:25:46PM +0100, Rafael J. Wysocki wrote:
> >> The other one is that what happens during async resume does not meet
> >> the assumptions of commit 5797b1c18919 (for example, it can easily
> >> produce a chain of interdependent work items longer than 8) and so it
> >> breaks things.
> > Ah, that's fascinating. But aren't CPUs all brought up online before devices
> > are resumed? If so, the max_active should already be way higher than the
> > WQ_DFL_MIN_ACTIVE. Also, are these multi node NUMA machines? Otherwise, it
> > really shouldn't affect anything. One easy way to verify would be just
> > bumping up WQ_DFL_MIN_ACTIVE and see what happens.
> 
> I've increased WQ_DFL_MIN_ACTIVE from 8 to 32 and all the system 
> suspend/resume issues went away. :)

Ah, okay, that's surprising. Lemme look at the code again. I gotta be
missing something.

Thanks.

-- 
tejun