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