Add some tools to test various real time Linux features

[thom24]

A pull request [1] has been opened in the OpenWrt core repository to introduce the PREEMPT_RT kernel configuration option for x86_64, arm64, and RISC-V architectures.
Enabling PREEMPT_RT makes it essential to analyze and characterize the kernel’s real-time performance. To support this, this pull request integrates existing tools for real-time behavior analysis into OpenWrt.

Some tools require the new tracers introduced in [1].

It can also be applied safely on openwrt-25.12 branch

[1] openwrt/openwrt#21413

[thom24]

Gentle ping :)

[thom24]

@GeorgeSapkin @BKPepe can you have a look please?

[GeorgeSapkin]

IDK, what any of these do so I can't really decide if they are worth merging. Perhaps @graysky2 has an opinion 👀

[graysky2]

I looked into RT kernels for routing before and I recall it being a disadvantage for most use cases (lower throughput, added complexity, more overhead). I think if you're doing a ton of VoIP stuff, it could make sense but most average users won't want a RT kernel (again from memory)

[thom24]

PREEMPT_RT does not mean performance. It is even more the opposite as there are lots of context switch (which cost a lot). PREEMPT_NONE (which is the default for most targets in OpenWrt) is the best model for servers in a general case.
The WIP PR [1] does not change that, it only add the possibility to select an other preemption model depending your use case and your requirements.
This PR adds some test packages which help you to characterize/evaluate the behavior of your kernel and help you to choose your preemption mode and configure your system. For example if you have latency requirements in the milliseconds range, PREEMPT_NONE does not work, PREEMPT_RT is overkill, so PREEMPT probably the best choice. But you need tools to test and characterize your system.
These packages allow you to do that, and they are also useful to track latency due to the hardware (like SMI on x86).

[1] openwrt/openwrt#21413

[thom24]

PR [1] has been merged, so now preemption model can be selected from the menuconfig, and all targets were aligned to use the PREEMPT_NONE model by default.

@GeorgeSapkin @BKPepe @graysky2 could we move forward ? Or NAK if you really don't want these packages.
But they are really useful to characterize your system, select your preemption model and track latency.

Thanks,

[1] openwrt/openwrt#21413

[GeorgeSapkin]

I don't have strong objections, besides the fact, that these are clearly niche tools, which this repo is full of. And which often go unmaintained, and then it's hard to figure out why they were added in the first place. E.g. everything that came from Turris (sorry for the call out) and then all people supporting those bits left.

The reason I pinged @graysky2 was because he often added something system-related and equally niche.

If nobody else has any strong feeling we can merge this.

@hnyman what do you think?

[hnyman]

I would say NAK (or at least some kind source-only flag for the packages).

Those tools will have a really small user interest, but not really from the general embedded populace to whom we mainly compile package binaries. I see no point to regularly compile those for the 30+ different architectures.

I agree with @GeorgeSapkin that eagerly introduced and then forgotten niche packages are unoptimal in the long run.

[thom24]

I'm fine with a kind of souce-only flag. I understand that providing binaries for these kind of packages which are mostly used for development and debugging in very specific cases is something you do not want.
Maybe also put these source-only packages in a dedicated place/directory.

Except if I missed something such flag does not exist for now.

[GeorgeSapkin]

@thom24 considering this has an org copyright, and you're clearly skilled enough to know how to use these tools, why not set up a custom feed with your packages? You can even have a GitHub action that rebuilds them daily for any architectures you need if this depends on specific kernel versions.