sample/zbus: qemu_nios2 needs faster tick for zbus test with picolibc

[keith-packard]

Picolibc is enough faster than the minimal C library that the zbus benchmark will likely complete in well under 10ms on qemu_nios2. As this target cannot provide a clock at higher resolution than the system tick, we need to increase that rate to get a non-zero runtime for this benchmark.

This is a replacement for #53589 and a response to #53563, which didn't quite resolve the issue on this target.

Signed-off-by: Keith Packard [email protected]

[rodrigopex]

I was considering finding a less verbose way to do that. However, in this case, you had to copy twice the same setup for adding only one line in each copied chunk. I could not find any way cleaner to do that. Any advice @nashif @galak @PerMac? I am citing you guys because of the twister's maintainers list.

[keith-packard]

I was considering finding a less verbose way to do that. However, in this case, you had to copy twice the same setup for adding only one line in each copied chunk. I could not find any way cleaner to do that. Any advice @nashif @galak @PerMac? I am citing you guys because of the twister's maintainers list.

Yeah, having some ability to have per-target extra config flags would be useful here. I did try changing the config globally but couldn't find a combination that worked on every target.

[nashif]

would something like this work?

--- a/samples/subsys/zbus/benchmark/sample.yaml
+++ b/samples/subsys/zbus/benchmark/sample.yaml
@@ -19,6 +19,7 @@ tests:
       - CONFIG_BM_ONE_TO=8
       - CONFIG_BM_MESSAGE_SIZE=256
       - CONFIG_BM_ASYNC=y
+      - arch:nios2:CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000
   sample.zbus.benchmark_sync:

any other suggestions? This can also be

`platform::CONFIG_...

or we can go fancy and have

CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 if arch == nios2 but that is more complicated to implement.

[keith-packard]

would something like this work?

I'd say it's entirely up to you; obviously any of the suggestions you made would be fine. Take that as a feature request for some future release?

I'd suggest not waiting for that though; no reason to block fixing things while the tooling catches up with this kind of improvement.

[nashif]

I'd suggest not waiting for that though; no reason to block fixing things while the tooling catches up with this kind of improvement.

PR on the way :)

[nashif]

#53725

[keith-packard]

#53725

🥳 I'll give this a try and post some review there when I get a chance.

[rodrigopex]

It would be better to use the new approach for conditional extra_config.

[keith-packard]

It would be better to use the new approach for conditional extra_config.

I was hoping to see fixes for west proposed so this patch wouldn't break existing usage, but sure, I'll push the updated version.

[stephanosio]

@keith-packard Could you rebase?

[keith-packard]

Looks like this change was merged along with #53338 although it wasn't included in that PR. I discovered this when attempting to rebase and got 'noop' ...