racarr__ | :) | 00:07 |
---|---|---|
RAOF | Uh, why is lp:mir/devel failing 32 tests on my machine? | 01:33 |
* RAOF pulls again to see if it's transient. | 01:34 | |
RAOF | Hm, no... | 01:51 |
RAOF | ...something fishy in the build/ directory. | 03:07 |
RAOF | Bah. | 03:07 |
RAOF | Bah. *Why* can't you find a vtable, damnit? | 05:49 |
RAOF | Oh, because the destructor definition is missing. | 05:54 |
RAOF | Good job, error message! | 05:54 |
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
alan_g | alf_: (if you're about) do you have headspace to help me think through bug 1317370? | 09:00 |
ubot5 | 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:00 |
alf_ | alan_g: sure | 09:01 |
alan_g | I've slightly rewritten BufferQueue::compositor_release() and instrumented the test... | 09:01 |
alan_g | What is happening is in the path current_compositor_buffer == buffer.get() && ready_to_composite_queue.empty() | 09:02 |
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:03 |
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:05 |
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:06 |
alan_g | Here's the rewrite: http://paste.ubuntu.com/7593504/ | 09:08 |
alan_g | Line 30 is the "fix" | 09:08 |
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:10 |
alan_g | With one I get the "Normal" behaviour | 09:11 |
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: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_g | unaffected | 09:19 |
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:20 |
alan_g | Hmm. 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)" 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:00 |
alan_g | alf_: thanks. I now understand what is wrong. Just need a valid test that doesn't have this issue | 10:02 |
alan_g | alf_: 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_g | alf_: OK, I'll leave it alone | 10: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 | ||
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:16 |
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:17 |
kgunn | rather than dist-upgrdae | 19:18 |
camako | kgunn, ack | 19:18 |
ogra_ | Saviq, its still in proposed | 19:18 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
camako | kgunn ^^ | 19:24 |
kgunn | wow | 19:25 |
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:27 |
kgunn | ogra_: i think i have a new theme song for ci-train | 19:28 |
kgunn | http://www.youtube.com/watch?v=3MLp7YNTznE | 19:28 |
ogra_ | kgunn, sadly blocked in germany :P | 19:29 |
kgunn | Ozzy Osbourne "Crazy Train" | 19:29 |
* 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:30 |
AlbertA | lol... | 19:32 |
AlbertA | "Im going off the rails on a crazy train" | 19:33 |
anpok_ | Saviq: thx | 19:40 |
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:38 |
josharenson | http://pastebin.ubuntu.com/7597245/ | 20:40 |
josharenson | fginther ^ | 20:40 |
fginther | josharenson, thx | 20:41 |
fginther | josharenson, do you know what package provides mir_performance_tests? | 22:09 |
josharenson | its part of the mir test suite | 22:11 |
josharenson | fginther ^ | 22:11 |
fginther | josharenson, thx | 22:11 |
racarr__ | :) Got some new fake event hub capabilities | 23:03 |
racarr__ | synthetic touchscreens of various configurations | 23:03 |
AlbertA | anpok: yeah you were right the osk top letters was alpha^2 issue | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!