Received-SPF: pass (google.com: domain of linux-kernel+bounces-56965-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <2f125955-8c7c-465c-938c-8768f7ca360b@samsung.com>
Date: Wed, 7 Feb 2024 19:55:51 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] PM: sleep: Restore asynchronous device resume
 optimization
Content-Language: en-US
To: Tejun Heo <tj@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "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
From: Marek Szyprowski <m.szyprowski@samsung.com>
In-Reply-To: <ZcOyW_Q1FC35oxob@slm.duckdns.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
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>

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. :)

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland