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: <CAPDyKFqic-rFe95g657MdZHtdPXTmFmYQG4ZSBV56S3DhMEF-A@mail.gmail.com>
Date: Thu, 29 Jan 2026 17:30:09 +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 Wed, 28 Jan 2026 at 18:14, Bart Van Assche <bvanassche@....org> wrote:
>
> On 1/28/26 5:23 AM, Ulf Hansson wrote:
> > How does other block device drivers do this?
>
> The role of the Linux kernel is to provide mechanisms while remaining as
> policy-neutral as possible. In other words, it is up to user space to
> decide whether to enable or to disable runtime PM.

I agree.

>
> For UFS devices some form of runtime PM is enabled by default for
> battery-powered devices because otherwise the impact on battery life
> would be unacceptable. If the latency impact of runtime resume is not
> acceptable for some applications then it is up to user space software to
> tune runtime power management as necessary.

Seems reasonable to me, but how do we distinguish that it's a
battery-powered device?

Are we considering UFS a technology that is used solely for
battery-powered devices or is there something else we consider?

>
> Additionally, cpu_latency_qos_update_request() is called by the UFS
> driver during runtime suspend and resume to prevent that CPU frequency
> scaling negatively affects UFS processing latency. I'd like to move
> these cpu_latency_qos_update_request() calls from the UFS driver into
> the block layer core because I think that every block driver that
> supports runtime power management needs this.

While this is more about performance tuning rather than I/O request
latency in regards to runtime PM, I certainly agree that this belongs
in the common block code.

Although, a tricky part when moving it upwards into the more common
layers, is that those latency constraint values may have a very
different impact, as the numbers are platform specific, right?

Thanks a lot for your comments!

Kind regards
Uffe