[04:53] <RAOF> git rebase --exec is really nice.
[04:56] <RAOF> Relatedly: I wonder how I could make linking libmirserver.so faster :)
[04:58] <anpok> linking with gold?
[05:02] <RAOF> Hm, maybe.
[05:04] <RAOF> Nah, not substantially faster.
[05:15] <RAOF> Oh, *slighty* faster, in that it fails to link libmirplatform :)
[05:55] <duflu> RAOF: AFAIK it's the shear number of symbols. And most of those will be from template usage. Haven't audited it but have been meaning to. Sometimes you can make simple changes to reduce the problem...
[06:38] <anpok> hm our ci is not pulling in stable phone overlay - is that intended?
[06:50] <duflu> Not sure. Is there a distro project to see what's in the overlay?
[07:08] <anpok> it des not pick up the liibnput library I need
[07:08] <anpok> so I guess it does not include the overlay ppa
[08:44] <duflu> greyback: Thanks for the pointers. Turns out nothing in our stack holds wake locks for the sake of performance (the kernel stats show powerd's wake locks are hardly used). But also adding wake locks to prevent idling is not enough to make a noticeable improvement to graphics...
[08:45] <greyback> duflu: so it seems something else is managing gpu clock speed?
[08:45] <greyback> is it gpu clock speed, or cpu, you suspect?
[08:46] <duflu> greyback: Yeah the scaling governors are annoyingly independent
[08:46] <duflu> greyback: CPU is sufficient. while(true); is enough to make the rest of the system smooth
[08:46] <anpok> hm governors and wake locks are two competing proposals on managing system throttling
[08:46] <duflu> anpok: Yes, I can see now they are separate
[08:47] <anpok> wake locks in powerd, thats requestSysState?
[08:47] <greyback> duflu: is surfaceFlinger doing anything special?
[08:47] <greyback> anpok: yep
[08:49] <anpok> greyback: android kernels do have special fds to request the system to stay awake.. and there are code paths to manage hand overs before and after ipc ..
[08:51] <duflu> greyback: SurfaceFlinger is not special. We can get the same performance (or better?) with Mir in simple non-nested server testing. The challenge is how to keep parallelism and performance high in the nested scenario, because that's where we're going to sleep.
[08:51]  * greyback grumbles about nested servers again
[08:51] <duflu> Seems like we need more parallelism still
[08:51] <anpok> duflu: hm maybe looking at lttng traces can help
[08:52] <duflu> If for no other reason than to keep the system awake
[08:52] <anpok> i.e. compare with and without touch interaction?
[08:53] <duflu> Also, triple buffers seems to be an important factor in keeping the system busy and awake. Double (or dynamic scaling) makes it sleepy and slow.
[08:53] <anpok> or is it really just that touch adds more work for the currently running process to dispatch the input events and hence keeps the cpu (and the other cores) spinning
[08:53] <duflu> anpok: Yes there are many ways to trick the system into staying fast
[08:54] <duflu> like while(true) {}
[08:54] <alf_> mzanetti: Saviq: Is there anything more to do for silo 14, or is it "Ready for QA"?
[08:55] <mzanetti> alf_, Saviq was running some tests still I think. good to go from my end
[08:56] <alf_> mzanetti: ack, thanks
[08:57] <duflu> It's also possible mt-cpufreq is less good at its job than others
[09:02] <duflu> because doing the same things on mako and arale you can see mako scales up to multiple cores immediately. arale stutters and takes a lot of convincing before it does (mt-cpufreq)
[09:08] <duflu> greyback: Any way to get Qt to thread more?
[09:09] <greyback> duflu: that's a very vague question
[09:09] <guest42315> :))
[09:09] <duflu> greyback: I mean use more threads to do the same work, rather than doing so much in one event loop
[09:09] <greyback> it has 1 thread for input & event processing, one thread for rendering
[09:09] <duflu> Yeah I've gathered that
[09:10] <duflu> Just being hopeful
[09:10] <greyback> answer is no
[09:10] <duflu> I have a prototype branch to get Mir itself to thread more
[09:11] <greyback> that doesn't strike me as solving a problem. It's treating a symptom.
[09:11] <greyback> using more threads to try to convince the kernel scheduler that you need more cores, to trick performance to improve
[09:11] <duflu> greyback: Absolutely. However the problem seems to be compiled into the Android kernel. Not even a module with parameters we can tweak. The most you can do is convince it to wake up more
[09:12] <greyback> we have the kernel source and can tweak it
[09:12] <greyback> or at least understand what metrics it's using
[09:12] <duflu> greyback: That's fine. I can find the source already. Unfortunately different devices are different.
[09:13] <greyback> true
[09:13] <greyback> but they all run android, so must have lots in common
[09:14] <duflu> greyback: I don't think it's that we need to waste energy waking up, just find more points of premature sleeping (like Mir's socket send issue)
[09:15] <duflu> and not sleep in those places where we need to do time critical tasks after the sleep
[09:16]  * duflu tries getting some stats
[09:35] <alan_g> duflu: mcphail http://unity.ubuntu.com/mir/ is back! (Work still in progress to fix properly)
[09:52] <mcphail> alan_g: woohoo! Cheers
[09:53] <mcphail> (no excuse for me to avoid some hacking this evening, now)
[10:55] <Saviq> alf_, mzanetti, just finishing up, sorry for the delay
[10:55] <mzanetti> nw... partly my fault anyways...
[11:30] <alf_> Saviq: np, thanks
[11:31] <davmor2> mzanetti: you don't need to accept blame any more it's all Saviq 's fault again ;)
[11:31] <Saviq> davmor2, sure he does, I'm his mgr now
[11:31] <mzanetti> haha
[11:32] <mzanetti> yeah... all the blame will fall through directly to me now, maybe amplified a bit
[11:32] <davmor2> mzanetti: hahaha
[11:33] <Saviq> isn't that what being a mgr means?
[11:34] <davmor2> Saviq: no it means it's all your fault you de man ;)
[11:35] <Saviq> damn, I wonder if I can still reconsider...
[11:37] <ogra_> davmor2, a proper manager delegates propely to his minions ;)
[11:42] <davmor2> ogra_: He has to accept the blame to protect his minions, so they get to do all the work, pretty sure those are the rules ;)
[11:42] <davmor2> ogra_: the delegation is only on work not blame ;)