[00:07] :) [01:33] Uh, why is lp:mir/devel failing 32 tests on my machine? [01:34] * RAOF pulls again to see if it's transient. [01:51] Hm, no... [03:07] ...something fishy in the build/ directory. [03:07] Bah. [05:49] Bah. *Why* can't you find a vtable, damnit? [05:54] Oh, because the destructor definition is missing. [05:54] Good job, error message! === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:00] alf_: (if you're about) do you have headspace to help me think through bug 1317370? [09:00] bug 1317370 in Mir "[regression] [BufferQueue] BufferQueueTest.compositor_never_owns_client_buffers is very slow (up to 30 seconds) on fast machines" [Medium,Triaged] https://launchpad.net/bugs/1317370 [09:01] alan_g: sure [09:01] I've slightly rewritten BufferQueue::compositor_release() and instrumented the test... [09:02] What is happening is in the path current_compositor_buffer == buffer.get() && ready_to_composite_queue.empty() [09:03] If we don't release the lock and yield() then we see the slowdown [09:03] We don't do the slowdown if the test runs on a single core [09:03] s/do/see/ [09:05] So something is slowing getting a client buffer into the ready queue - or at least making it visible to the compositor thread [09:05] alan_g: does your instrumentation indicate any thread starvation issues? [09:05] When the slowdown happens the composite thread loops many more times [09:06] Normal: [09:06] DEBUG client looping: 0.014147 [09:06] DEBUG server looping: 0.0141657, iterations: 5837 [09:06] Slow: [09:06] DEBUG client looping: 10.1207 [09:06] DEBUG server looping: 10.1208, iterations: 1922091 [09:08] Here's the rewrite: http://paste.ubuntu.com/7593504/ [09:08] Line 30 is the "fix" [09:10] Without the fix the *fewer* cores available the better. If I tie half of them up I can get [09:10] DEBUG client looping: 2.62574 [09:10] DEBUG server looping: 2.62577, iterations: 509508 [09:11] With one I get the "Normal" behaviour [09:13] I guess the client thread never gets a bite at the BufferQueue mutex - but there is an existing yield() while the compositor has a buffer [09:14] * alan_g feels the facts are there and the conclusion will be obvious after it has been stated. [09:19] alan_g: another interesting data point would be how the number of buffers in the queue affects the runtime (the test tries with 2 to 5 buffers) [09:19] unaffected [09:20] E.g. (output from each iteration) [09:20] DEBUG client looping: 8.67461 [09:20] DEBUG server looping: 8.67464, iterations: 1657258 [09:20] DEBUG client looping: 10.1207 [09:20] DEBUG server looping: 10.1208, iterations: 1922091 [09:20] DEBUG client looping: 7.21194 [09:20] DEBUG server looping: 7.21197, iterations: 1391499 [09:20] DEBUG client looping: 9.53182 [09:20] DEBUG server looping: 9.53185, iterations: 1840078 [09:31] Hmm. The problem scenario is when pending_client_notifications.empty() - I mis-thought that a pending notification would be the problem. [10:00] alan_g: another data point: in my runs the primary cause of delay is waiting for client_buffer_guard at the end of the "for (int i = 0; i < 1000; ++i)" loop [10:00] alf_: the time is spent in contention over client_buffer_guard - the "compositor" keeps grabbing it while compositing the same buffer [10:00] snap! [10:02] alf_: thanks. I now understand what is wrong. Just need a valid test that doesn't have this issue [10:03] alf_: One last question: do you find the original BufferQueue::compositor_release() logic clearer or my rewrite? [10:13] alan_g: I think the flow is a bit more straightforward in the original, i.e., if (can_and_should_replace_current) { do replace } if (should_release) { do release } [10:14] alf_: OK, I'll leave it alone === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === alan_g is now known as alan_g|lunch === pete-woods is now known as pete-woods-lunch === alan_g|lunch is now known as alan_g === pete-woods-lunch is now known as pete-woods === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === chihchun_afk is now known as chihchun === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|lunch === om26er_ is now known as om26er === chihchun is now known as chihchun_afk === dandrader|lunch is now known as dandrader [19:16] Saviq: if you're on, we had to rebuild/retest mir due to earlier mess up with ci train and papi2.0 [19:16] but with hardly any change to our silo we're seeing lots of failures, is this expected? (due to "Define XDG_*_DIRS so that autopilot tests don't have to (and thus caused failures in unity8 autopilot)" [19:17] kgunn, fix for that just landed [19:17] kgunn, upgrade ubuntu-touch-session and reboot [19:17] thanks [19:17] AlbertA: anpok_ camako ^ [19:18] rather than dist-upgrdae [19:18] kgunn, ack [19:18] Saviq, its still in proposed [19:19] ogra_, huh? [19:19] oh, i'm lying ... migrated this second [19:19] * ogra_ starts an image build [19:19] ogra_, yeah, I just cleared the silo :) [19:19] ogra_, says 25 minutes ago, not this second ;) [19:20] Saviq, argh [19:20] you wiped it [19:20] Saviq, its gone from proposed [19:20] ogra_, wdym? https://launchpad.net/ubuntu/+source/ubuntu-touch-session [19:21] ogra_, if anything, the train let me do something wrong [19:21] ogra_, having first informed me that I could [19:21] Saviq, if you clean before it moved from proposed (which it had not) then it vanishes [19:21] ogra_, wha? LP says it's there... [19:22] ogra_, train doesn't let you merge+clean unless it's in the destination [19:22] ogra_, I didn't "wipe_only" [19:22] Saviq, seems rmadison had a hiccup or something [19:22] never trust LP [19:22] ogra_, https://ci-train.ubuntu.com/job/landing-002-3-merge-clean/7/parameters/ [19:23] the LP page tells you it migrated before it actually did [19:23] ogra_, tell the train that :| [19:23] that uses rmadison i hope [19:23] anyway, triggering a build ... 69 should be ready in ~1.5h with the fix [19:24] kgunn ^^ [19:25] wow [19:27] kgunn, I'm just gonna test pre-0.2.0 (without unity8 fix) [19:27] we should get the same failures [19:27] camako: ack [19:28] ogra_: i think i have a new theme song for ci-train [19:28] http://www.youtube.com/watch?v=3MLp7YNTznE [19:29] kgunn, sadly blocked in germany :P [19:29] Ozzy Osbourne "Crazy Train" [19:30] * ogra_ humms along [19:30] :) [19:30] lol [19:30] me too [19:30] "its crazy, but that's how it goes" [19:30] yeah [19:32] lol... [19:33] "Im going off the rails on a crazy train" [19:40] Saviq: thx [20:38] josharenson, what is needed to run the glmark2 tests on a freshly flashed touch image? [20:38] fginther 1 min. making a pastebin [20:38] thx [20:40] http://pastebin.ubuntu.com/7597245/ [20:40] fginther ^ [20:41] josharenson, thx [22:09] josharenson, do you know what package provides mir_performance_tests? [22:11] its part of the mir test suite [22:11] fginther ^ [22:11] josharenson, thx [23:03] :) Got some new fake event hub capabilities [23:03] synthetic touchscreens of various configurations [23:47] anpok: yeah you were right the osk top letters was alpha^2 issue