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

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

[Daniel Wagner]

With -u, the latency timerlat reports runs until the measuring thread
is back in user space. Nothing keeps that thread's memory resident,
so under memory pressure the kernel reclaims its code, stack and libc
pages, and the page faults on the way back to user space count as
latency.

On a Raspberry Pi 3 (PREEMPT_RT 6.12) under stress-ng --class memory,
timerlat reported up to 40 ms for the user-space threads, which took
283 major faults, while the kernel threads' latency stayed below
1 ms. cyclictest under the same load: 133 ms without -m (mlockall),
0.9 ms with it.

With this change timerlat reports 0.9 ms for the user-space threads
under the same load, and they take no major faults.

Lock the user-space threads' memory before they start measuring, as
cyclictest -m does.

Signed-off-by: Daniel Wagner <wagi@monom.org>
---
Changes in v2:
- Shorted comment.
- Moved the mlock up before the sched switch as suggested by John
- Link to v1: https://patch.msgid.link/20261112-rtla-mlock-v1-1-418986711b20@monom.org
---
 tools/tracing/rtla/src/timerlat_u.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/tracing/rtla/src/timerlat_u.c b/tools/tracing/rtla/src/timerlat_u.c
index c80edaf07b00..5e7a23fb9fc3 100644
--- a/tools/tracing/rtla/src/timerlat_u.c
+++ b/tools/tracing/rtla/src/timerlat_u.c
@@ -15,6 +15,7 @@
 #include <pthread.h>
 #include <sys/wait.h>
 #include <sys/prctl.h>
+#include <sys/mman.h>
 
 #include "common.h"
 #include "timerlat_u.h"
@@ -37,6 +38,13 @@ static int timerlat_u_main(int cpu, struct timerlat_u_params *params)
 	cpu_set_t set;
 	int retval;
 
+	/*
+	 * Fault in and lock all memory before switching to a real-time
+	 * priority, so that page faults don't show up as latency.
+	 */
+	if (mlockall(MCL_CURRENT | MCL_FUTURE))
+		err_msg("Could not lock timerlat u memory: %s\n", strerror(errno));
+
 	/*
 	 * This all is only setting up the tool.
 	 */

---
base-commit: ee83899302a0457a3ba47464a13e8682bd7ba27d
change-id: 20261112-rtla-mlock-2a572f10533e

Best regards,
--  
Daniel Wagner <wagi@monom.org>

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

[John Ogness]

Hi Daniel,

On 2026-11-13, Daniel Wagner <wagi@monom.org> wrote:
> diff --git a/tools/tracing/rtla/src/timerlat_u.c b/tools/tracing/rtla/src/timerlat_u.c
> index c80edaf07b00..5e7a23fb9fc3 100644
> --- a/tools/tracing/rtla/src/timerlat_u.c
> +++ b/tools/tracing/rtla/src/timerlat_u.c
> @@ -37,6 +38,13 @@ static int timerlat_u_main(int cpu, struct timerlat_u_params *params)
>  	cpu_set_t set;
>  	int retval;
>  
> +	/*
> +	 * Fault in and lock all memory before switching to a real-time
> +	 * priority, so that page faults don't show up as latency.
> +	 */

It isn't because the page faults show up as latencies. It is because
doing non-real-time work with a real-time priority is stealing the CPU
away from other real-time tasks that presumably have actual real-time
work to do.

This program peforms severeal non-real-time activities with the
real-time priority, which is not setting a good example. But I am only
reviewing your patch, not the full source.

John

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

[Tomas Glozar]

On Fri, Nov 13, 2026 at 3:56 PM John Ogness <john.ogness@linutronix.de> wrote:
>
> It isn't because the page faults show up as latencies. It is because
> doing non-real-time work with a real-time priority is stealing the CPU
> away from other real-time tasks that presumably have actual real-time
> work to do.
>
> This program peforms severeal non-real-time activities with the
> real-time priority, which is not setting a good example. But I am only
> reviewing your patch, not the full source.
>
> John
>

The only other activities the user thread performs with RT priority on
before entering the timerlat interface read loop are setting the
cgroup and opening the timerlat interface file descriptor. I agree
that ideally, setting the priority should be done just before the
loop.

However, I don't think either activity takes too long, so the
difference is probably negligible in practice. Unlike mlockall, which
(if I understand your point correctly) might pre-fault from disk

Tomas