rt-app: Add memrun event with read, write, and chase workload types#147
Open
sarav wants to merge 2 commits intoscheduler-tools:masterfrom
Open
rt-app: Add memrun event with read, write, and chase workload types#147sarav wants to merge 2 commits intoscheduler-tools:masterfrom
sarav wants to merge 2 commits intoscheduler-tools:masterfrom
Conversation
| add_cgroups(); | ||
|
|
||
| /* Initialize mem_chase pointer chains for all resources */ | ||
| for (i = 0; i < opts.resources->nresources; i++) { |
Member
There was a problem hiding this comment.
Why this is not part of init_resources ?
Member
There was a problem hiding this comment.
we want to keep all resources init in same place
Author
There was a problem hiding this comment.
Yes this should be moved. But should I move this to parse_task_event_data or does it have to be init_resources_data()? Problem with the latter is that we don't have the event details (buf size, stride, pattern, etc) in there.
So I either have to put it in parse... or pass these args (union of per resource args) into init_resource_data().
Which approach do you prefer?
Member
There was a problem hiding this comment.
Passing the union of per resource arg into init_resource_data is the cleanest solution IMO
Member
|
Also I forgot to mention that you should update the doc/tutorial.txt with the description of the new events |
added 2 commits
April 24, 2026 10:50
Add a new "memrun" event that supports three memory workload types
beyond the existing "mem" (memset) and "iorun" (write syscall):
- "write": byte-at-a-time volatile stores over a sized buffer
- "read": byte-at-a-time volatile reads over a sized buffer
- "chase": pointer-chasing over a linked list for memory latency
measurement, inspired by lmbench's lat_mem_rd
The read and write implementations use nested loops to avoid modulo
overhead — the outer loop counts full buffer passes, the inner loop
does sequential access. This gives symmetric read/write performance
(unlike the legacy "mem" event which uses vectorized memset).
The chase workload supports configurable buffer size, stride, and
pattern. The "random" pattern uses bit-reversed pointer ordering
(from lmbench) to defeat hardware prefetchers, while "sequential"
uses a simple stride-based chain. Buffer size controls which cache
level is stressed.
JSON syntax:
"memrun": { "type": "chase", "size": 262144, "stride": 64,
"pattern": "random", "count": 50000000 }
"memrun": { "type": "read", "size": 10485760, "count": 10485760 }
"memrun": { "type": "write", "size": 10485760, "count": 10485760 }
The existing "mem" integer event is unchanged for backward
compatibility.
Verified on ARM64 with simpleperf showing clear differentiation
across workload types in instruction and bus-access stats.
Signed-off-by: Saravana Kannan <saravanak@kernel.org>
Add POSIX semaphore-based synchronization events. Unlike suspend/resume
and signal/wait which are stateless (wakeups are lost if the target
thread isn't blocked yet), semaphores accumulate posts — a sem_post
increments the counter and a sem_wait decrements it or blocks if zero.
This enables reliable cross-thread wakeup patterns where the poster
may run ahead of the waiter, such as pipeline stages where an upstream
thread can complete multiple frames before a preempted downstream
thread gets to run.
JSON syntax:
"sem_post": "sem_name" // increment, never blocks
"sem_wait": "sem_name" // decrement or block until > 0
Both sem_post and sem_wait events sharing the same name reference
the same underlying semaphore, initialized to 0 at startup.
Verified on ARM64 with two test cases:
- Basic producer/consumer with synchronized handoff
- Early-post test where waker posts 5 times before sleeper starts
(3s delay), confirming sleeper consumes accumulated posts
without blocking
Signed-off-by: Saravana Kannan <saravanak@kernel.org>
Author
|
Found a bunch of bugs in the previous implementation when I tested esoteric combinations of these memrun events. Fixed them all.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a new "memrun" event that supports three memory workload types beyond the existing "mem" (memset) and "iorun" (write syscall):
The read and write implementations use nested loops to avoid modulo overhead — the outer loop counts full buffer passes, the inner loop does sequential access. This gives symmetric read/write performance (unlike the legacy "mem" event which uses vectorized memset).
The chase workload supports configurable buffer size, stride, and pattern. The "random" pattern uses bit-reversed pointer ordering (from lmbench) to defeat hardware prefetchers, while "sequential" uses a simple stride-based chain. Buffer size controls which cache level is stressed.
JSON syntax:
"memrun": { "type": "chase", "size": 262144, "stride": 64,
"pattern": "random", "count": 50000000 }
"memrun": { "type": "read", "size": 10485760, "count": 10485760 }
"memrun": { "type": "write", "size": 10485760, "count": 10485760 }
The existing "mem" integer event is unchanged for backward compatibility.
Verified on ARM64 with simpleperf showing clear differentiation across workload types in instruction and bus-access stats.