On 2026-10-12 19:10, Alexander Kanavin wrote:
The consensus in the patch review was that a nearly 100x time increase in
TCG vs. real silicon is still pathological and needs to be investigated
(assuming all targets run exact same test code). So can you look into that,
perhaps with guidance from Trevor (or maybe Trevor can also check what is
happening)?
Also a 1800s timeout when the test takes 1702s is too close, and that can
easily go over on loaded autobuilder machines. For reliability, it would
need to be at least double what you observe. But if we don't make progress
with figuring out the slowness, we should probably disable the specific
slow test, rather than let it run for 30 minutes.
Hi Alex,
The actual test is 100 threads × 100,000 elements (10M lock-guarded
next() calls)
I did tests with different config combinations , total work fixed at
1,000,000 next() calls and varied only the thread count:
config native x86-64 qemuriscv64 TCG slowdown
10 threads x 100k 1.35s 15.5s ~11x
100 threads x 10k 0.10s 110.5s ~1100x
Trevor, do you have any suggestions how we can handle this situation ?
If no other options, I will disable the specific slow test .
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#247793):
https://lists.openembedded.org/g/openembedded-core/message/247793
Mute This Topic: https://lists.openembedded.org/mt/121659949/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
