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: <CAPDyKFrNHc4FexuTbdWM-Kvo0mn9C51nJN5b=e0jZR8miFho+g@mail.gmail.com>
Date: Tue, 3 Feb 2026 12:28: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 Mon, 2 Feb 2026 at 23:47, Bart Van Assche <bvanassche@....org> wrote:
>
> On 1/29/26 8:30 AM, Ulf Hansson wrote:
> > Seems reasonable to me, but how do we distinguish that it's a
> > battery-powered device?
>
> RPM can be enabled or disabled from the scripts executed during boot.
> At build time it should be known whether or not the device is battery-
> powered.

Okay, so user space needs to make a decision, no matter what.

The point here from my side, is that the default behaviour differs
(RPM suspend may be allowed at boot - or not), based on the storage
subsystem in charge of the device.

I wonder if it would make sense to try to align the behaviour to
common default, between the subsystems that have enabled support RPM.
Or maybe it's just too late for that.

>
> > Are we considering UFS a technology that is used solely for
> > battery-powered devices or is there something else we consider?
>
> I think there are devices that use UFS and that are not battery-powered,
> e.g. smart TVs.
>
> > 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?
>
>  From the UFS driver:
>
> cpu_latency_qos_update_request(&hba->pm_qos_req, on ?
>                                 0 : PM_QOS_DEFAULT_VALUE);
>
> In other words, if no block I/O is ongoing the CPU latency is set to
> PM_QOS_DEFAULT_VALUE (-1 or no constraint) and if block I/O is ongoing
> the maximum CPU latency is set to 0 (no CPU power savings allowed). I
> think these parameters are independent of the platform and storage
> device :-)

I see, thanks for sharing the details! :-)

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.

Kind regards
Uffe