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: <CAPDyKFqQCtXzRruVSy0RLfWw11=TB+HAqN=+0P7St=aovZOoEg@mail.gmail.com>
Date: Thu, 5 Feb 2026 12:26:20 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Bart Van Assche <bvanassche@....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 Tue, 3 Feb 2026 at 19:10, Bart Van Assche <bvanassche@....org> wrote:
>
> On 2/3/26 3:28 AM, Ulf Hansson wrote:
> > I guess the question then is, do we always want zero latency, which I
> > assume must be costly from a power savings point of view. At least
> > during the idle period, while not serving I/O and waiting for the
> > device to be runtime suspended.
>
> Block I/O latency suffers if a CPU core enters a lower power state while
> waiting for an I/O completion. Hence the choice in the UFS driver for
> not allowing CPU cores to enter a lower power state while any block I/O
> is in progress.

Right, this seems reasonable to me too. Although, in a way it is a
policy decision, as it means favoring block I/O performance, above
trusting the cpuidle governor to pick an optimal low power state (from
performance and power point of view) for the CPUs.

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

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?

Kind regards
Uffe