[02:57] <georgeascott> I'm trying to find general mobile support/tips non distro specific
[02:58] <georgeascott> google keeps automatically redirecting me to a page saying to log in from a pc to set up google voice
[15:06] <persia> JamieBennett: Looking at https://wiki.ubuntu.com/ARM/CasperSpeedup, have you determined if the long-running processes are processor-limited, io-limited, or ipc-limited?
[15:06] <JamieBennett> persia: not yet and unsure how to check them for this
[15:06] <JamieBennett> I have managed to shave 7 seconds off though so far
[15:07] <JamieBennett> seems slow-down occurs around debconf-communicate calls which is suspicious
[15:07] <persia> That seems to be a lot of them, yeah :)
[15:08] <persia> I also wonder if some could be parallelised, like `dpkg -P gdm-guest-session`
[15:08] <persia> Dunno if "time" is available in initramfs, but that's how I usually check the state of various resource uses.
[15:09] <persia> (and if you alter the format arguments, can usually return some interesting values)
[15:09] <JamieBennett> persia: that dpkg can be replaced with rm -r /usr/share/gdm/guest-session
[15:10] <persia> I don't think that's the best answer, because that won't clear the configs.
[15:10] <persia> Nice thing about `dpkg -P` is that is removes the associated configuration.
[15:11] <JamieBennett> but we are looking at speed for a live image
[15:11] <persia> Yeah.
[15:12] <lool> JamieBennett: I'm pretty sure there are some low hanging fruits in perl code, perhaps bugs in the interpreter or just very slow constructs that we only notice on armish CPUs; I'm sure you'll find out  :-)
[15:12] <persia> So, if we don't remove the configuration, that might end up leaving a gdm that is configured for guest sessions without the helper binary, which gives a poor user experience in the live environment.
[15:12] <JamieBennett> lool: its just identifying test cases to shake them out
[15:13] <lool> JamieBennett: Oh you mean you need some smaller test cases reproducing the issues?
[15:13] <lool> JamieBennett: Does dpkg-reconfigure $package reproduce the slowness?  Would that be a good enough test case?
[15:13] <persia> Right.  At least for the debconf-communicate case, we can probably just profile it running in an installed system and determine some of the issues.
[15:14] <JamieBennett> lool: it would be to ensure they are the same yes, but the perl issue ?
[15:16] <persia> JamieBennett: dpkg-reconfigure *is* perl :)
[15:17] <lool> JamieBennett: debconf is usually perl + shell bits, so you will likely see it
[15:17] <lool> JamieBennett: Once thing you can do is strace -t or -tt or -ttt to see which processes take what time to run
[15:18] <persia> And you can profile perl to see which specific bits are slow.
[15:18] <lool> There are better tools out there for profiling, but strace is a good first start if you don't yet know what's exactly involved in the problem
[15:19] <JamieBennett> OK, will do.
[15:20] <lool> JamieBennett: Oh -t/-tt etc. will but timestamps at the beginning of each line of strace output
[15:20] <lool> Forgot to explain that part
[15:21] <persia> JamieBennett: Last note is that I don't think it's worth trying to improve the speed of make-ssl-cert or fontconfig-voodoo untilthe rest is hit.  Limited parallelisation plus solving the debconf stuff should be a huge win, at which point it's proabably worth reprofiling.
[15:23] <JamieBennett> persia: OK
[15:24] <persia> JamieBennett: Was that the sort of review you sought when you asked for review in the meeting, or do you want something more detailed?
[15:26] <JamieBennett> persia: between you and lool that's exactly what I needed. I'll probably prod you again when I have the results of the strace at some point
[15:27] <persia> Sure :)
[17:13] <Jones_Hugo> Hi there... any1 around?
[17:19] <Jones_Hugo> Been tryind to load Hildon-Desktop on karmic... any1 got it done?
[17:19] <Jones_Hugo> trying*
[18:24] <dneary> Hi
[18:24] <dneary> I just installed UNR 8.10 on a Samsung NC20
[18:25] <dneary> Is the background fading in & out supposed to be really slow? I mean, 3 frames with 0.5fps?
[18:26] <dneary> I assume it's a consequence of my graphics card not being supported (I had to install the community driver for the VX800 chipset on install)
[18:28] <dneary> No-one in?
[18:31] <asac> havent heard of NC20
[18:31] <asac> but if you had to installsomething that wasnt there oob ...  i would guess its pretty sure that
[18:31] <asac> dneary: why not UNR 9.10 ? ;)
[18:31] <asac> or was that a typo?
[18:31] <dneary> That's the one
[18:32] <dneary> I missed the 8 button
[18:32] <dneary> So typo, yes
[18:32] <asac> you have xserver-xorg-video-openchrome installed ?
[18:33] <asac> guess you followed instructions here: https://help.ubuntu.com/community/OpenChrome ?
[18:34] <dneary> I followed the instructions at the top of the NC20 page
[18:34] <dneary>  https://launchpad.net/~xorg-edgers/+archive/drivers-only/+build/1307486
[18:35] <dneary> sudo dpkg -i /media/disk/xserver-xorg-video-via_0.2.904~svn814-0ubuntu0tormod_i386.deb
[18:35] <dneary> sudo dpkg -i /media/disk/xserver-xorg-video-openchrome_0.2.904~svn814-0ubuntu0tormod_i386.deb
[18:35] <dneary> First during installation, then again after installation
[18:35] <asac> ok
[18:36] <asac> anyway. at best check in -desktop ;)
[18:36] <dneary> Yeah
[18:36] <asac> but from what i understand thats the latest crack
[18:36] <asac> in edgetsr
[18:36] <dneary> First off the liveCD, then an install
[18:36] <asac> edgetrs
[18:36] <asac> what i mean is that xserver is a ubuntu-desktop topic ;)
[18:36] <asac> not -mobile
[18:36] <dneary> edgerts
[18:36] <dneary> asac, UNR doesn't work out of the box either :)
[18:37] <asac> yes, but if its a driver issue its not UNR :-P
[18:39] <dneary> OK
[18:39] <dneary> But one thing which could help is to know if the UNR desktop requires 3d to work (you could be using some GL or clutter by default in the desktop maybe?
[18:40] <Jones_Hugo> Been trying to load Hildon-Desktop on karmic... any1 got it done?
[18:40] <dneary> If you are, the chances are that with unaccelerated 2D it's going to be like running Tuxracer on the typical Nvidia chip in 2000
[20:36] <JamieBennett> lool: around? output of an strace on /usr/lib/user-setup/user-setup-apply http://pastebin.ubuntu.com/343814/
[21:06] <lool> JamieBennett: -t is a bit light, only second information
[21:06] <lool> You might want -tt
[21:07] <lool> JamieBennett: Start with -e trace=process
[21:07] <lool> That limits to process creation / destruction events
[21:07] <JamieBennett> lool: looks like its the reading of templates.dat which takes around 4 seconds
[21:07] <lool> Oh that could be
[21:08] <lool> It's 2 MB which is a bit heavy to read on each debconf-communicate
[21:08] <JamieBennett> lool: yes I think its 2.4MB
[21:08] <JamieBennett> which is read each debconf-communicate which adds 4 seconds to each of the scripts that use it
[21:08] <lool> Yeah it's pretty clearly reading of this file
[21:08] <lool> It's odd that it takes so long to *read* it
[21:09] <JamieBennett> not sure how to 'fix' that though
[21:09] <JamieBennett> apart from a) not read it or b) cut the file down
[21:09] <lool> JamieBennett: Can you try 'cat /var/cache/debconf/templates.dat'
[21:09]  * JamieBennett reboots the babbage
[21:09] <lool> Oh on a real system is fine
[21:11] <lool> JamieBennett: I mean I find it odd that *reading* 2 MB of data takes so long, unless it's parsed at the same time
[21:11] <lool> It could be slow to read it because it's stuffed into some perl data structure
[21:14] <JamieBennett> time cat /var/cache/debconf/templates.dat
[21:14] <JamieBennett> real	0m6.727s
[21:14] <JamieBennett> user	0m0.000s
[21:14] <JamieBennett> sys	0m0.036s
[21:14] <JamieBennett> or is that not what your after?
[21:15] <lool> So the cat took 6 seconds to run?
[21:15] <lool> For a 2 MB file?
[21:15] <lool> That's huge
[21:15] <JamieBennett> on my quad core
[21:15] <JamieBennett> 2m16 on the ARM
[21:16] <lool> Uh
[21:16] <lool> time cat /var/cache/debconf/templates.dat >/dev/null
[21:16] <lool> cat /var/cache/debconf/templates.dat > /dev/null  0,00s user 0,00s system 0% cpu 0,006 total
[21:16] <JamieBennett> :)
[21:16] <lool> on my laptop
[21:16] <lool> and on my desktop
[21:16] <lool> cat /var/cache/debconf/templates.dat > /dev/null  0,00s user 0,01s system 5% cpu 0,198 total
[21:16] <JamieBennett> 0.147s on the babbage
[21:16] <lool> Ok
[21:18] <lool> JamieBennett: So if you look at debconf-communicate, it starts with Debconf::Db->load
[21:18] <lool> Here it's enough to load templates.dat
[21:18] <lool> What you can try is creating a smaller test case by cp /usr/bin/debconf-communicate debconf-test
[21:18] <JamieBennett> I see the load
[21:18] <lool> add an exit 0 after the load and run debconf-test
[21:18] <lool> time ./debconf-test
[21:18]  * JamieBennett does that
[21:18] <lool> ./debconf-test  0,20s user 0,00s system 97% cpu 0,204 total
[21:18] <lool> on my laptop
[21:20] <JamieBennett> 0m4.632s
[21:20] <lool> So that's clearly your culprit
[21:20] <JamieBennett> what we expected
[21:20] <lool> time perl -e 'use Debconf::DbDriver; $templates=Debconf::DbDriver->driver(Debconf::Config->templates);'
[21:20] <lool> Should be the same thing, but I'm following the debconf code
[21:25] <lool> JamieBennett: The actual driver to create the templates.dat structure in memory is /usr/share/perl5/Debconf/DbDriver/File.pm
[21:25] <lool> It has a bit of debug
[21:25] <lool> You could enhance it with some timing info
[21:26] <lool> JamieBennett: and actual parsing is done by /usr/share/perl5/Debconf/Format/822.pm
[21:26] <JamieBennett> OK, I'll add some timestamps to see what's happening
[21:27] <lool> JamieBennett: With these last two, you're probably able to construct a small perl program which just parses the rfc2822 data in templates.dat and is too slow
[21:28] <lool> JamieBennett: Another approach is to question the usage of this format; you could propose usage of alternate formats (e.g. binary mmap-able sqlite db or something)
[21:28] <JamieBennett> lool: seems like a big change doing that though
[21:28] <lool> JamieBennett: When you have a small perl program, either you can change the perl style to be more efficient, or it might be an issue in the perl interpreter itself
[21:29] <lool> e.g. misaligned memory accesses or unoptimized code path on arm
[21:29] <lool> JamieBennett: I don't think it's that big a change, it's all configurable, see /etc/debconf
[21:29] <lool> Name: templatedb
[21:29] <lool> Driver: File
[21:29] <lool> Mode: 644
[21:29] <lool> Filename: /var/cache/debconf/templates.dat
[21:29] <lool> So you'd be creating e.g. Driver: sqlite
[21:29] <lool> Anyway, better to look into why it's slow first
[21:30] <lool> JamieBennett: When you have some data, talk to cjwatson
[21:30] <JamieBennett> lool: I'll get the timing info and we can decide the course of action from there.
[21:30] <JamieBennett> will do
[21:30] <lool> is the d-i/debconf guru and will have a better taste than I have to decide where to fix debconf slowness
[21:30] <lool> it might be he knows of more options or has a preference for one
[21:30] <JamieBennett> lool: OK, thanks for the help.
[21:30] <lool> Ack
[21:50] <JamieBennett> lool: OK so its definitely in /usr/share/perl5/Debconf/Format/822.pm but its not that its slow, its that the read() is being called many many times. Just trying to locate what calls it
[21:55] <JamieBennett> lool: 	while (! eof $this->{_fh}) {
[21:55] <JamieBennett> 		my ($item, $cache)=$this->{format}->read($this->{_fh});
[21:55] <JamieBennett> 		$this->{cache}->{$item}=$cache;
[21:55] <JamieBennett> 	}
[21:55] <JamieBennett> Is the culprit
[21:55] <JamieBennett> in File.pm
[21:55] <JamieBennett> (called twice strangely but its the second call to it that take 3s +)