linux-kernel - Re: [BUG] - Short freezes in gameplay due to MMC_CAP_AGGRESSIVE

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4f1d5c9a-f261-49da-9ae6-f068bcd7402c@acm.org>
Date: Thu, 5 Feb 2026 06:21:52 -0800
From: Bart Van Assche <bvanassche@....org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
 Ricky WU <ricky_wu@...ltek.com>,
 Matthew Schwartz <matthew.schwartz@...ux.dev>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
 linux-block <linux-block@...r.kernel.org>
Subject: Re: [BUG] - Short freezes in gameplay due to MMC_CAP_AGGRESSIVE_PM on
 RTS525A card reader

On 2/5/26 3:26 AM, Ulf Hansson wrote:
> The other concern I was trying to point out, is that using the runtime
> PM suspend/resume callbacks for managing the QoS constraint isn't
> really a good fit in my opinion, because of the potential idle period
> beyond the point when I/O was completed and when we may be waiting for
> the device to be runtime suspended (especially when runtime PM
> autosuspend is used).
> 
> More precisely, during this idle period there is no point in keeping
> the QoS constraint as it would mean potentially wasting unnecessary
> energy by preventing low power states for CPUs. Ideally, I think it
> would be better if we could monitor the I/O request queue to manage
> the QoS constraint directly. Perhaps that is what you suggested too, I
> just didn't get it. :-)

Hmm ... the block layer RPM code monitors the request queue, isn't it?
I don't see how the request queue could be monitored more directly than
how the block layer RPM code does it today - by checking the counter of
the number of requests that is in flight?

Deciding that the I/O request queue is empty is not possible without
waiting until the idle period has expired, isn't it?

> That said, speaking about runtime suspend for UFS. Is runtime PM
> enabled for the UFS card too or is it just the UFS host controller
> that supports it?

It depends on the decisions made by the manufacturer of the device that
includes the UFS device.

In multiple recent UFS-powered devices RPM is enabled for both the UFS
device and the UFS host controller.

Bart.