[00:45] <Cytotoxic> !OPS
[00:45] <Cytotoxic> !ops
[00:50] <Cytotoxic> !ops
[00:51] <Cytotoxic> !ops
[00:53] <Meow234> !ops
[00:53] <Meow234> !help
[00:53] <Meow234> !ops
[00:53] <dtchen> seriously, your hostmask gives you away entirely.
[00:54] <Meow234> i was adapting
[00:54] <Meow234> magic of lymphocytes
[03:29] <yodgo> i adapted
[03:30] <yodgo> !ops
[03:31] <dtchen> RAOF: FWIW, I'd favour a linux-backport-modules-nouveau approach
[03:31] <dtchen> backports*
[03:41] <RAOF> dtchen: What benefits does that have?
[03:41] <dtchen> RAOF: you leave the existing stack alone
[03:41] <dtchen> people opt in for any possible regressions
[03:42] <maco> just like l-b-m-alsa
[03:42] <RAOF> Is this the benefits over "nouveau-kernel-source" or over trying to backport nouveau to our existing drm?
[03:42] <dtchen> the latter
[03:43] <RAOF> Right.  I don't think that backporting nouveau to our drm is a great idea, either, although I haven't looked closely at precisely what it would require.
[03:43] <StevenK> RAOF: Nouveau also requires it's own DRM stack?
[03:44] <maco> StevenK: i think its more to do with the backporting part...
[03:44] <RAOF> StevenK: No, but it requires a _newer_ drm stack than we've got.
[03:44] <maco> old drm + new nouveau
[03:45] <RAOF> drm-next is regularly merged into the nouveau tree; that's not going to be in Lucid's kernel.
[03:45] <RAOF> (Or, rather, it's not going to be in 2.6.32, and we're not going to have 2.6.33)
[03:47] <dtchen> yeah, that makes some of my powerdown work rather interesting
[03:48] <StevenK> RAOF: Right, a newer DRM stack is okay, but it does mean some interesting integration work
[03:49] <RAOF> The actual drm-next patch against our kernel is 2.9MB; that's been thrown out as a non-option.
[03:50] <yodgo> How sexy is my ride?
[03:50] <yodgo> http://www.youtube.com/watch?v=uEO2eRw4y5Y
[03:51] <RAOF> That includes all the work in the intel driver and ati driver, and apparently the ati driver will want _some_ of it for Lucid, too, so it might be possible to have a substantially smaller patch.
[04:16] <yodgo> How sexy is my F40PH?
[04:16] <yodgo> http://www.youtube.com/watch?v=uEO2eRw4y5Y
[04:59] <MBCR> !ops
[05:00] <RAOF> Again?
[05:01] <MBCR> fuck ubuntu
[13:03] <apw> Keybuk, what was the magic to get the initcalls stuff into a piccy?
[13:47] <apw> smb, rtg, Keybuk, http://people.canonical.com/~apw/boot-speed/
[13:47] <apw> comparisons with the initial initramfs parallel thingy
[13:48] <apw> csurbhi1, ^^
[13:48] <csurbhi1> populate_rootfs is not parallel here
[13:48] <smb> look below
[13:49] <apw> those are _two_ graphs without and with your patch
[13:49] <apw> saves about .4s by the looks of it
[13:50] <smb> looks so for me as well
[13:51] <rtg> apw, makes my neck hurt
[13:51] <smb> or rather .40s ?
[13:51] <apw> heh :)
[13:51] <smb> which is the same
[13:51] <apw> heh yea
[13:51] <smb> but looks more impressive
[13:51] <rtg> smb, how about .40000s ?
[13:52] <apw> wow thats a lot
[13:52] <smb> even more impressive :-D
[13:53] <smb> apw, your second graph seems to start later without any action...
[13:54] <smb> Oh, they probably both start at .18 but the second graph's axis starts at .15...
[13:54] <apw> smb, i don't see that, they are labedlled in differnt things
[13:56] <smb> apw, funny, now that I made the window longer I see the 0.08 starting points...
[13:57] <apw> they are very big images
[13:57] <smb> apw, definitely. /me is jojoing up and down
[13:58] <apw> its acutally looks more like .3 of a second actually
[13:59] <smb> might be. hard to say without a number at the end (after)
[13:59] <apw> still not to be sneezed at
[13:59] <apw> 2% of the total to be found for the whole boot to go from 25->10s
[14:01] <smb> Surely agreed. 
[14:03] <smb> Not too much left to be optimized by parallelizing. piix_init might give a fract but might be required to be where it is. Can't read the scribbely small things before
[14:03] <smb> Though it might depend on isapnp in some cases...
[14:28] <apw> csurbhi, rtg, smb, ok updated charts with a third graph ...
[14:29] <apw> http://people.canonical.com/~apw/boot-speed/
[14:29] <apw> the third one is just parallelising the initramfs start
[14:29] <apw> about identicle to the second one in overall time
[14:30] <apw> we may save .3 of a second turning of ISA ... its a lot of cost considering almost noone has it!
[14:30] <smb> apw, Thats good. So even with the more minimal change the same gain is done
[14:30] <rtg> apw, are you booting this on a quad-core ?
[14:31] <apw> rtg nope this is on the reference dell 10v with SSD
[14:31] <csurbhi> basically moving the rootfs call before does not gain so much 
[14:31] <csurbhi> ?
[14:31] <csurbhi> right 
[14:31] <apw> ie a challenged machine
[14:31] <smb> apw, I recently read somewhere that they start to have sort of ISA buses for certain internal functions...
[14:31] <apw> csurbhi, knowing we can move it earlier for the same cost is good to know
[14:32] <apw> right now its not helping any bug if isa pnp was quicker it might be useful... now we know
[14:32] <apw> and we know its not _slower_ overlapping the earlier boot too which we didn't before
[14:32] <apw> DOH
[14:32] <apw> ^^ to smb's comment
[14:34] <smb> apw, Heh, yeah. More guessing at that part but it might be an alternative compared to i2c things...
[14:35] <mjg59> You need ISA
[14:35] <apw> mjg59, for?
[14:35] <mjg59> What the kernel calls CONFIG_ISA is actually support for non-PCI onboard devices
[14:35] <mjg59> And also PCMCIA
[14:35] <mjg59> You might be able to lose ISAPNP, which is what would probably take time
[14:36] <mjg59> PCMCIA has its own enumeration, and onboard devices will be in PNPBIOS or ACPIPNP tables
[14:36] <mjg59> So you'd lose support for autoloading modules for ISAPNP network cards and sound cards, but I don't think that works anyway
[14:37] <apw> i was just wondering about changing the default for enable noisapnp
[14:38] <apw> if its going to cost me .4s during boot!
[14:39] <smb> apw, question would be if anything later really depends on that
[14:39] <apw> yeah well my dell boots without :)
[14:39] <mjg59> You'd want to check with Scott, but I don't think isapnp modaliases work with udev module loading
[14:43] <apw> yeah i doubt its a viable option, but booting with it turned off saves .3s
[14:43] <apw> just as a kernel option off
[14:44] <apw> its very expensive
[14:45] <dandel> hmm further testing on bug 484943 reveals that it's  fixed in latest git, at least on kernel 2.6.32-rc8.
[14:45] <smb> apw, Though if that could be done async and nothing really waits on it early you still could safe
[14:45] <apw> yep ... testing the effects of asyncing that thing now
[14:45] <apw> moblin never needed to fix it cause they turn it off i suspect
[14:46] <apw> Keybuk, i think i foudn the rest of the time moblin saves... no isa and no initramfs -> .8 of a second total start time
[18:47] <akheron> smb, apw: I was finally able to test the upstream patch in http://bugzilla.kernel.org/show_bug.cgi?id=14700 and it seems to work
[18:48] <akheron> my wife gave birth to my second son yesterday morning, so I got delayed a bit :)
[18:50] <smb> akheron, heh, congrats. Thanks for the testing. I would think this now will go upstream+stable and then back. But it probably takes a bit
[18:50] <jjohansen> akheron: congrats
[18:50] <akheron> thanks
[18:51] <akheron> it doesn't matter for me if it takes a bit
[18:52] <akheron> at least I have a bootable system now, using my own patched 2.6.31-15
[18:52] <akheron> as long as lucid works when I eventually upgrade :)
[18:54] <smb> Yeah, there should be enough time for that :)
[20:33] <apw> Keybuk, about ?
[21:15] <ukev> hi
[21:15] <ukev> how can I check if this patch is integrated into ubuntu? http://patchwork.kernel.org/patch/60322/