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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAPDyKFqUw-HaKpvqBzoYm8K5gTjdwskAEcWGxnMHaj17QcKLjQ@mail.gmail.com>
Date: Thu, 5 Feb 2026 15:55:42 +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 Thu, 5 Feb 2026 at 15:21, Bart Van Assche <bvanassche@....org> wrote:
>
> 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?

Right, this is how it works today. We would need something additional
to what we have, to allow us to better manage performance
optimizations dynamically for block I/O. Exactly how to implement
this, needs further exploring, at least from my side.

FYI, related to this, there is a series from Qcom [1], that in
principle wants to allow some of the CPUs to enter deep idle states,
while keeping others to only shallow idle states. This is especially
useful for some UFS based platforms it seems.

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

Okay, thanks for letting me know and taking your time to answer all my
questions!

Kind regards
Uffe

[1]
[PATCH v2 0/5] PM QoS: Add CPU affinity latency QoS support and
resctrl integration
https://lore.kernel.org/all/20250721124104.806120-1-quic_zhonhan@quicinc.com/