Re: [PATCH] rtla/timerlat: Lock the memory of the user-space threads

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-11-13 11:07:15 [+0100], Tomas Glozar wrote:
> I agree, you are right. I was thinking about rtla setting
> /dev/cpu_dma_latency to 0 as an option rather than by default (unlike
> cyclictest, in that case). If rtla's idea is to measure the system in

Oh, yes. cpu_dma_latency is tricky because of all that happens to a
system setup and might not be expected and then people wonder why the
system behaves differently if a certain application runs.
mlock on the other hand is something clearly defined and explained why
it is important.

> its current configuration, it makes sense not to tune it by default.
> But the rtla user thread not having mlockall is a misconfiguration of
> the rtla thread (i,e. the measurement tool), not of the system.
> 
> Plus, cyclictest can run as a non-root user that might not have
> permissions to mlockall. That is not an issue with rtla, which always
> runs as root.

I don't think mlock is restricted to a root user. It might be that "huge"
application might exceed their memory limit during mlock and "usually"
their memory is just virtual and never faulted in.

> So I take that back. mlockall by default is fine.
Oki.

> Tomas

Sebastian