Hi John, Ahmed, John Kacur <jkacur@xxxxxxxxxx> writes: > On Fri, 22 Jan 2021, Ahmed S. Darwish wrote: > >> On Mon, Jan 18, 2021 at 06:00:46PM +0900, Punit Agrawal wrote: >> > >> > We ran into a few issues when trying to run rteval on arm64, arm and >> > i386. >> > >> > A few of the assumptions in rteval don't hold true on these systems. >> > >> >> For some embedded devices, it can be tough to use rteval with it. In >> general, it requires, *on the target*: >> >> 1. a full development toolchain (GCC, make, flex, bison, etc.) >> 2. a full kernel source tree >> 3. a full Python environment >> >> You can use a combination of stress-ng and cyclictest to properly >> evaluate your preempt_rt system latencies. Just make sure to exclude the >> stress-ng stressors which allocate real-time threads, which can (and do) >> conflict with the cyclictest ones. [...] > I agree, rteval wasn't designed for the embedded world. The reason for the > full development tool chain is to compile the kernel as a load, so if you > are compiling the kernel on a machine other than the device it is > targetted for, then rteval won't work. Also, yes it runs with a python3 > envirnoment, we still maintain a version for python2, but no new > development is occuring there. > > note that rteval can now run stress-ng too, but the default is without it. Thanks for your comments. Fortunately, the device filesystems can provide the dependencies (toolchain, python3, etc.) of rteval. But I'll keep in mind alternative ways to evaluate the system latencies when we can't. Thanks, Punit [...]
