Re: [libevl][PATCH 1/4] Copy dohell from Xenomai 3

["Jorge Ramirez-Ortiz, Gmail" <jorge.ramirez.ortiz@gmail.com>]

On 13/06/24 17:55:02, Philippe Gerum wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
> > On 13.06.24 16:23, Philippe Gerum wrote:
> >> 
> >> Tobias Schaffner <tobias.schaffner@siemens.com> writes:
> >> 
> >>> Dohell is used as the default load generator in Xenomai 3. Add it to
> >>> libevl to be able to stress the system while testing evl.
> >>>
> >> 
> >> dohell is obsolete. Let's move to stress-ng or something alike for x4.
> >> 
> >
> > See my comment on patch 3: If you can name a configuration of stress-ng
> > that stresses a co-kernel more than what dohell does, we can take it.
> > Otherwise, I would strongly recommend to not do less hell over here.
> >
> 
> The most important stress dohell applies is basically hackbench and a dd
> loop trashing the D-cache. The latter can be obtained with a combo of
> VM+I/O tests from stress-ng. So basically, the whole issue boils down to
> having hackbench on board, provided we cannot generate the same load
> profile with stress-ng with a CPU bound stressor. Besides, I never saw
> any added value in running ltp tests compared to a combo of stress-ng
> stressors when it comes to latency testing.
> 
> We obviously don't want to throw less hell, but throwing more obsolete
> stuff is not an option either. So that's a NAK for v4 ATM, I'll gather
> more information about how we could leverage stress-ng in order to
> compare to dohell. This is worth a shot.

I should start by apologizing for not having delivered a proper,
stress-ng case study yet. In my defense (if that counts), I got
sidetracked by day-to-day work and the long process of getting latmon gpio
support merged into Zephyr[1] — which ended up taking > six months of
back-and-forth.

BTW If you have access to one of these devices [2] (they’re inexpensive),
plus a couple of GPIOs on your Xenomai-enabled board and a network
interface, they make it quite practical to collect long-term traces in
an automated way.

So comming back to the discussion, I still believe that the better path
is to validate and if necessary extend stress-ng. Just as monitoring
tools like latmon dont belong in the Xenomai repository (the Zephyr work
above mentioned is a step on that direction), I think stress tools
should be kept out as well.

IMO this separation of concerns will also help those trying to decide
between PREEMPT_RT and Xenomai for their use cases.

[1] https://docs.zephyrproject.org/latest/samples/net/latmon/README.html
[2] https://docs.zephyrproject.org/latest/boards/nxp/frdm_k64f/doc/index.html