Cytotoxic | !OPS | 00:45 |
---|---|---|
Cytotoxic | !ops | 00:45 |
Cytotoxic | !ops | 00:50 |
Cytotoxic | !ops | 00:51 |
Meow234 | !ops | 00:53 |
Meow234 | !help | 00:53 |
Meow234 | !ops | 00:53 |
dtchen | seriously, your hostmask gives you away entirely. | 00:53 |
Meow234 | i was adapting | 00:54 |
Meow234 | magic of lymphocytes | 00:54 |
=== bjf is now known as bjf-afk | ||
yodgo | i adapted | 03:29 |
yodgo | !ops | 03:30 |
dtchen | RAOF: FWIW, I'd favour a linux-backport-modules-nouveau approach | 03:31 |
dtchen | backports* | 03:31 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
dtchen | yeah, that makes some of my powerdown work rather interesting | 03:47 |
StevenK | RAOF: Right, a newer DRM stack is okay, but it does mean some interesting integration work | 03:48 |
RAOF | The actual drm-next patch against our kernel is 2.9MB; that's been thrown out as a non-option. | 03:49 |
yodgo | How sexy is my ride? | 03:50 |
yodgo | http://www.youtube.com/watch?v=uEO2eRw4y5Y | 03:50 |
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. | 03:51 |
yodgo | How sexy is my F40PH? | 04:16 |
yodgo | http://www.youtube.com/watch?v=uEO2eRw4y5Y | 04:16 |
MBCR | !ops | 04:59 |
RAOF | Again? | 05:00 |
MBCR | fuck ubuntu | 05:01 |
apw | Keybuk, what was the magic to get the initcalls stuff into a piccy? | 13:03 |
apw | smb, rtg, Keybuk, http://people.canonical.com/~apw/boot-speed/ | 13:47 |
apw | comparisons with the initial initramfs parallel thingy | 13:47 |
apw | csurbhi1, ^^ | 13:48 |
csurbhi1 | populate_rootfs is not parallel here | 13:48 |
=== csurbhi1 is now known as csurbhi | ||
smb | look below | 13:48 |
apw | those are _two_ graphs without and with your patch | 13:49 |
apw | saves about .4s by the looks of it | 13:49 |
smb | looks so for me as well | 13:50 |
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:51 |
apw | wow thats a lot | 13:52 |
smb | even more impressive :-D | 13:52 |
smb | apw, your second graph seems to start later without any action... | 13:53 |
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:54 |
smb | apw, funny, now that I made the window longer I see the 0.08 starting points... | 13:56 |
apw | they are very big images | 13:57 |
smb | apw, definitely. /me is jojoing up and down | 13:57 |
apw | its acutally looks more like .3 of a second actually | 13:58 |
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 | 13:59 |
smb | Surely agreed. | 14:01 |
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:03 |
apw | csurbhi, rtg, smb, ok updated charts with a third graph ... | 14:28 |
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:29 |
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:30 |
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:31 |
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:32 |
smb | apw, Heh, yeah. More guessing at that part but it might be an alternative compared to i2c things... | 14:34 |
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:35 |
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:36 |
apw | i was just wondering about changing the default for enable noisapnp | 14:37 |
apw | if its going to cost me .4s during boot! | 14:38 |
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:39 |
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:43 |
apw | its very expensive | 14:44 |
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:45 |
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 | 14:46 |
=== bjf-afk is now known as bjf | ||
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:47 |
akheron | my wife gave birth to my second son yesterday morning, so I got delayed a bit :) | 18:48 |
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:50 |
akheron | it doesn't matter for me if it takes a bit | 18:51 |
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:52 |
smb | Yeah, there should be enough time for that :) | 18:54 |
apw | Keybuk, about ? | 20:33 |
ukev | hi | 21:15 |
ukev | how can I check if this patch is integrated into ubuntu? http://patchwork.kernel.org/patch/60322/ | 21:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!