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