userspace: add a performance test#10563
Conversation
Currently ztest delay is set to 100ms, which adds that time between each too ztest runs. This very quickly adds up to cause an IPC timeout in the kernel driver. That timeout isn't needed for SOF, set it to 1ms. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
When dynamically allocating thread stack with the current Zephyr implementation it's allocated uncached. So far there is no proper solution to support fully dynamic cached stack. Switch to the system stack pool until a solution is implemented. This only affects userspace threads currently. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
3 bytes per object aren't enough any more. Increase to 4 which still fits in an atomic 32-bit field. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Add a test to compare kernel and userspace performance when performing tight loop calculations with no API calls. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
| bool first = true; | ||
|
|
||
| for (;;) { | ||
| load_fn_t fn = (load_fn_t)k_event_wait(event, 0xffffffff, !first, K_FOREVER); |
There was a problem hiding this comment.
That is some serious event overuse to pass a value here 😆. You might also try k_poll_signal_raise(), it can pass a value too. The only catch is that we don't have enabled k_poll, so it won't help. I guess this is just a quick draft for tests, right?
There was a problem hiding this comment.
@softwarecki well, I do think it would be good to have it merged. "overuse" - well, maybe indeed this isn't how events are intended to be used, but I'd call it a "creative use" ;-)
There was a problem hiding this comment.
This would be the perfect place to use RTIO! Just kidding 😄 I'd suggest using something actually meant for passing data, maybe a FIFO or a queue? https://docs.zephyrproject.org/latest/kernel/services/index.html#data-passing
|
@lyakh ping - any update ? |
@lgirdwood I'm not sure what to do with this one - do we want it? It was created to debug an issue with userspace DP performance, which turned out to be because of uncached .text in userspace LLEXT modules. This PR cannot test that because it isn't loaded via LLEXT. So do we want it? If yes - which tests should we include? Just some dull number crunching or some HiFi? And in any case it seems lower priority than some other tasks on my plate right now |
3 participants
compare kernel- and userspace performance