/srv/irclogs.ubuntu.com/2014/06/05/#ubuntu-mir.txt

racarr__:)00:07
RAOFUh, why is lp:mir/devel failing 32 tests on my machine?01:33
* RAOF pulls again to see if it's transient.01:34
RAOFHm, no...01:51
RAOF...something fishy in the build/ directory.03:07
RAOFBah.03:07
RAOFBah. *Why* can't you find a vtable, damnit?05:49
RAOFOh, because the destructor definition is missing.05:54
RAOFGood job, error message!05:54
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
alan_galf_: (if you're about) do you have headspace to help me think through bug 1317370?09:00
ubot5bug 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/131737009:00
alf_alan_g: sure09:01
alan_gI've slightly rewritten BufferQueue::compositor_release() and instrumented the test...09:01
alan_gWhat is happening is in the path current_compositor_buffer == buffer.get() && ready_to_composite_queue.empty()09:02
alan_gIf we don't release the lock and yield() then we see the slowdown09:03
alan_gWe don't do the slowdown if the test runs on a single core09:03
alan_gs/do/see/09:03
alan_gSo something is slowing getting a client buffer into the ready queue - or at least making it visible to the compositor thread09:05
alf_alan_g: does your instrumentation indicate any thread starvation issues?09:05
alan_gWhen the slowdown happens the composite thread loops many more times09:05
alan_gNormal:09:06
alan_gDEBUG client looping: 0.01414709:06
alan_gDEBUG server looping: 0.0141657, iterations: 583709:06
alan_gSlow:09:06
alan_gDEBUG client looping: 10.120709:06
alan_gDEBUG server looping: 10.1208, iterations: 192209109:06
alan_gHere's the rewrite: http://paste.ubuntu.com/7593504/09:08
alan_gLine 30 is the "fix"09:08
alan_gWithout the fix the *fewer* cores available the better. If I tie half of them up I can get09:10
alan_gDEBUG client looping: 2.6257409:10
alan_gDEBUG server looping: 2.62577, iterations: 50950809:10
alan_gWith one I get the "Normal" behaviour09:11
alan_gI guess the client thread never gets a bite at the BufferQueue mutex - but there is an existing yield() while the compositor has a buffer09:13
* alan_g feels the facts are there and the conclusion will be obvious after it has been stated.09:14
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_gunaffected09:19
alan_gE.g. (output from each iteration)09:20
alan_gDEBUG client looping: 8.6746109:20
alan_gDEBUG server looping: 8.67464, iterations: 165725809:20
alan_gDEBUG client looping: 10.120709:20
alan_gDEBUG server looping: 10.1208, iterations: 192209109:20
alan_gDEBUG client looping: 7.2119409:20
alan_gDEBUG server looping: 7.21197, iterations: 139149909:20
alan_gDEBUG client looping: 9.5318209:20
alan_gDEBUG server looping: 9.53185, iterations: 184007809:20
alan_gHmm. The problem scenario is when pending_client_notifications.empty() - I mis-thought that a pending notification would be the problem.09:31
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)" loop10:00
alan_galf_: the time is spent in contention over client_buffer_guard - the "compositor" keeps grabbing it while compositing the same buffer10:00
alan_gsnap!10:00
alan_galf_: thanks. I now understand what is wrong. Just need a valid test that doesn't have this issue10:02
alan_galf_: One last question: do you find the original BufferQueue::compositor_release() logic clearer or my rewrite?10:03
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:13
alan_galf_: OK, I'll leave it alone10:14
=== 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
kgunnSaviq: if you're on, we had to rebuild/retest mir due to earlier mess up with ci train and papi2.019:16
kgunnbut 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:16
Saviqkgunn, fix for that just landed19:17
Saviqkgunn, upgrade ubuntu-touch-session and reboot19:17
kgunnthanks19:17
kgunnAlbertA: anpok_ camako ^19:17
kgunnrather than dist-upgrdae19:18
camakokgunn, ack19:18
ogra_Saviq, its still in proposed19:18
Saviqogra_, huh?19:19
ogra_oh, i'm lying ... migrated this second19:19
* ogra_ starts an image build 19:19
Saviqogra_, yeah, I just cleared the silo :)19:19
Saviqogra_, says 25 minutes ago, not this second ;)19:19
ogra_Saviq, argh19:20
ogra_you wiped it19:20
ogra_Saviq, its gone from proposed19:20
Saviqogra_, wdym? https://launchpad.net/ubuntu/+source/ubuntu-touch-session19:20
Saviqogra_, if anything, the train let me do something wrong19:21
Saviqogra_, having first informed me that I could19:21
ogra_Saviq, if you clean before it moved from proposed (which it had not) then it vanishes19:21
Saviqogra_, wha? LP says it's there...19:21
Saviqogra_, train doesn't let you merge+clean unless it's in the destination19:22
Saviqogra_, I didn't "wipe_only"19:22
ogra_Saviq, seems rmadison had a hiccup or something19:22
ogra_never trust LP19:22
Saviqogra_, https://ci-train.ubuntu.com/job/landing-002-3-merge-clean/7/parameters/19:22
ogra_the LP page tells you it migrated before it actually did19:23
Saviqogra_, tell the train that :|19:23
ogra_that uses rmadison i hope19:23
ogra_anyway, triggering a build ... 69 should be ready in ~1.5h with the fix19:23
camakokgunn ^^19:24
kgunnwow19:25
camakokgunn, I'm just gonna test pre-0.2.0 (without unity8 fix)19:27
camakowe should get the same failures19:27
kgunncamako: ack19:27
kgunnogra_: i think i have a new theme song for ci-train19:28
kgunnhttp://www.youtube.com/watch?v=3MLp7YNTznE19:28
ogra_kgunn, sadly blocked in germany :P19:29
kgunnOzzy Osbourne "Crazy Train"19:29
* ogra_ humms along 19:30
ogra_:)19:30
kgunnlol19:30
kgunnme too19:30
kgunn"its crazy,  but that's how it goes"19:30
ogra_yeah19:30
AlbertAlol...19:32
AlbertA"Im going off the rails on a crazy train"19:33
anpok_Saviq: thx19:40
fgintherjosharenson, what is needed to run the glmark2 tests on a freshly flashed touch image?20:38
josharensonfginther 1 min. making a pastebin20:38
fgintherthx20:38
josharensonhttp://pastebin.ubuntu.com/7597245/20:40
josharensonfginther ^20:40
fgintherjosharenson, thx20:41
fgintherjosharenson, do you know what package provides mir_performance_tests?22:09
josharensonits part of the mir test suite22:11
josharensonfginther ^22:11
fgintherjosharenson, thx22:11
racarr__:) Got some new fake event hub capabilities23:03
racarr__synthetic touchscreens of various configurations23:03
AlbertAanpok: yeah you were right the osk top letters was alpha^2 issue23:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!