linux-kernel - Re: [PATCH v1] PM: sleep: Restore asynchronous device resume optimization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0iLZ_U92q_Jt-91StZhUPdeZRD05MpDLxmaGaAa2-v1KQ@mail.gmail.com>
Date: Mon, 12 Feb 2024 15:57:21 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Tejun Heo <tj@...nel.org>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	"Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM <linux-pm@...r.kernel.org>, 
	Ulf Hansson <ulf.hansson@...aro.org>, Nathan Chancellor <nathan@...nel.org>, 
	LKML <linux-kernel@...r.kernel.org>, 
	Stanislaw Gruszka <stanislaw.gruszka@...ux.intel.com>, Lai Jiangshan <jiangshanlai@...il.com>, 
	Naohiro.Aota@....com, kernel-team@...a.com
Subject: Re: [PATCH v1] PM: sleep: Restore asynchronous device resume optimization

Hi,

On Fri, Feb 9, 2024 at 1:20 AM Tejun Heo <tj@...nel.org> wrote:
>
> Hello,
>
> On Thu, Feb 08, 2024 at 08:47:12AM +0100, Marek Szyprowski wrote:
> > I've tried to get drgn running on the test target, but then I've noticed
> > that it is not possible to run it on ARM 32bit target, as it requires
> > PROC_KCORE support, which is 'Visible if: PROC_FS [=y] && MMU [=y] &&
> > !ARM [=y]' for some reasons.
>
> Bummer. I instrumented code on my test setup (x86) and couldn't repro usage
> of the dfl_pwq, unfortuantely.

On x86 there are fewer device links representing dependencies between
devices, because it doesn't use fw_devlink which is used on ARM
platforms (and other DT-based), so on x86 it is less likely to
reproduce this.

> Independent of understanding what's going on with the system_unbound_wq, the
> correct solution seems like using a dedicated workqueue with raised
> min_active. Just posted the patchset to do that:
>
>   http://lkml.kernel.org/r/ZcVtzJvJCRV5OLM-@slm.duckdns.org

LGTM, thanks!