LazyInstanceTest.PriorityInversionAtInitializationResolves flaked under Fuchsia/x64 FYI bot |
||
Issue descriptionLazyInstanceTest.PriorityInversionAtInitializationResolves flaked in https://build.chromium.org/p/chromium.fyi/builders/Fuchsia/builds/14476, seemingly because the low-priority thread was apparently not scheduled in a timely manner: [00041.813] 03997.04059> [ RUN ] LazyInstanceTest.PriorityInversionAtInitializationResolves [00041.814] 03997.04059> [3:1283822319:0302/013537.191789:28088985:ERROR:platform_thread_fuchsia.cc(42)] Not implemented reached in static void base::PlatformThread::SetCurrentThreadPriority(base::ThreadPriority)setting ThreadPriority 0 [00041.814] 03997.04059> ../../base/lazy_instance_unittest.cc:321: Failure [00041.814] 03997.04059> Expected: (base::TimeTicks::Now() - test_begin) < (base::TimeDelta::FromSeconds(5)), actual: 7.89604 s vs 5 s [00041.814] 03997.04059> [ FAILED ] LazyInstanceTest.PriorityInversionAtInitializationResolves (7909 ms) [00041.814] 03997.04059> [736/2839] LazyInstanceTest.PriorityInversionAtInitializationResolves (7909 ms) This is especially impressive given that we don't actually implement platform-native thread priorities on Fuchsia (see https://cs.chromium.org/chromium/src/base/threading/platform_thread_fuchsia.cc?gsn=SimpleThread&l=40). The test does run 4x the number of "foreground" threads than there are CPU cores, which perhaps means that there is too much context-switching going on for QEMU to execute things at anything approaching normal speed?
,
Mar 15 2018
Sigh... while QEMU is great at exercising data races, it's ridiculously slow at processing multiple threads...
,
Mar 15 2018
To be fair to QEMU, we're running a new kernel under nested virtualization; it's possible that we're hitting a glut of IPIs that are then super-expensive to emulate, for example.
,
Mar 15 2018
True, well the mix of the two is sure a good stress test for us but it appears to breakdown under high thread counts (i.e. same with RacyCleanup test on TaskScheduler). PS: what's IPI?
,
Mar 15 2018
IPI = Inter-Processor Interrupt. If you have a multi-core system and perform an IPC, e.g. sending a message to a service process, then an IPI may be dispatched to an idle core on the system to wake it to run the target process. It is a little strange that we see this flake so often on Fuchsia/x64 but not Fuchsia (dbg), if it is really an emulation performance issue; we'll investigate, though, and see if we can pin things down.
,
Jan 11
There don't seem to be any further occurrences if this issue. |
||
►
Sign in to add a comment |
||
Comment 1 by w...@chromium.org
, Mar 15 2018