=== Tim-away is now known as TimStarling [06:03] this is only a little OT: where can I put a script to load netconsole? === asac_ is now known as asac === asac_ is now known as asac === mcasadevall is now known as NCommander === mcasadevall is now known as NCommander [14:25] smb_tp: remember my "boot pauses" https://bugs.edge.launchpad.net/linux/+bug/254668 [14:25] Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] [14:26] rtg, did you have a chance to look at the lpia trees i pushed yesterday? [14:26] wondering if it is related to "Tainted: P M " https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317227 [14:26] Malone bug 317227 in linux "skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP " [Undecided,New] [14:27] or there is anything related, given you looked at that boxes dmesg more than once [14:32] apw: its on my todo list for this morning. [14:32] no worries [14:33] CarlFK1, Hi, yes I do remember, though I have been distracted by other stuff since. From somewhere I heard that people had success with jaunty for that... [14:33] * smb_tp looks at the link [14:42] smb_tp: ill try a jaunty kernel and comment both of those bugs [14:43] CarlFK1, Ok, I am not really convinced they are tied together but thats just by quickly looking upon it [14:45] smb_tp: 2.6.27 stable updates pushed [14:45] rtg, Ok, thanks [14:46] rtg, that was stable update to -11, right? [14:46] Doh, 2.6.27.11 I meant to say [14:46] smb_tp: 2.6.27.11 [14:47] ok [14:47] not to be confused with -11 :) [14:47] yeah, thought of it the moment I hit enter [14:48] The upload of this will have to wait until we got the current one to -updates [14:55] smb_tp: fixed the pause - yay [14:55] "failed to start X"... not so yay. [14:55] nvidia... [14:56] CarlFK1, So rather yayno. First is good, now I only would have to find which of the zillion changes this was. [20:39] well [20:39] and I stress that this isn't final [20:39] with just kernel and udev updates, it looks like jaunty takes 10s less time to boot than intrepid already [20:39] (no switching to ext4 or anything like that) [20:40] I've read similar anecdotal evidence. Is that with readahead? [20:40] same readahead as intrepid [20:40] I did reprofile it to make sure [20:40] before both [20:40] so that shouldn't effect the numbers [20:41] grub to full login is now 61s [20:41] huh, I didn't know we were doing readahead. Is that part of initramfs? [20:41] it's part of the normal system booy [20:41] /etc/rcS.d/S01readahead [20:42] has been since, err, hoary [20:42] I'm pretty sure it was Mataro we put that in, the food still haunts my memories [20:42] so it wasn't warty [20:42] drat, I was hoping readahead would get us the next 10 second win. [20:43] sorting out readahead might buy us more [20:43] but this is SSD [20:44] readahead counts for less than 1s of the boot to read in the entire profile [20:44] I'm working on LRM boot time link. that ought to buy us 2-4 secs [20:44] one thing ive noticed is that boot time degrades over time =/ [20:44] switching from "read in entire profile then move on" to "read in by access order throughout the boot" may be an improvement of a few seconds, since less ram is required [20:44] pwnguin: sure, because your readahead profile gets increasingly out of date [20:44] so you need to load more from disk [20:44] Keybuk: have you messed with ext4? [20:45] Keybuk: there's also the matter of fragmentation [20:46] pwnguin: ext* are largely self-defragmenting [20:46] rtg: no, noet yet [20:46] my next task is to sort out module-init-tools [20:46] I'm hoping for another couple of seconds there [20:46] Keybuk: and yet, i have documented proof that super duper hack involving tar retrieves a few seconds [20:46] then sort out the hardware clock and console setup (on the sprint agenda), I'm hoping *that's* another couple of seconds [20:47] a few sends here, a few seconds there, .... [20:47] pwnguin: sure, but that's for a different reason ;) it realigns your disk order with your readahead profile (which is in that kind of order) [20:47] it could be that the fs groups writes together [20:47] there's a sleep in procps I'm going to uncover [20:47] so theres fewer seeks [20:47] that's almost 2s [20:47] thats an odd place for a sleep [20:47] Keybuk: what do you think about removing the png-ification on bootchart, and leaving it as svg? [20:47] rtg: I know [20:47] pwnguin: SVGs are a pain [20:48] name me a program that can view them [20:48] inkscape? [20:48] inkscape can't view them, it can edit them [20:48] firefox [20:48] firefox can't view them last time I looked unless they're embeded in html [20:48] * Keybuk doesn't understand why people mind the pngification [20:49] it basically defeats datamining [20:49] rtg: well, with all the bits and pieces everywhere, including ext4 ... I'm hoping for X in 15s for jaunty [20:49] pwnguin: I don't follow? bootchart doesn't include itself in its own chart ;) [20:49] now if we could speed up that pig GDM startup [20:49] rtg: this is rather less than what I thought we could get - so I'm really happy [20:50] you guys have done great work [20:50] kernel accounts for roughly half of that improvement from what I can tell [20:50] Keybuk: imagine being able to graph the bootchart over time [20:50] pwnguin: personally I disable stop-bootchart and run it by hand once I get to the logged in session anyway [20:51] pwnguin: again, irrelevant, since bootchart doesn't include itself [20:51] you start generating the png at the point you've stopped collecting data [20:51] im vastly confused [20:51] bootchart generates a chart of your boot [20:51] yes [20:51] at some point, it decides to stop collecting data [20:51] that's when it generates the chart [20:51] indeed [20:51] so the time to generate the chart is irrelevant to the length of time it takes to boot [20:51] and then it writes to $version-$date-$uid [20:52] now, some people install bootchart [20:52] and leave it installed [20:52] i agree, but i never said anything about bootchart itself [20:52] and complain that it slows down login or something, because it's generating the png [20:52] but well [20:52] that's silly [20:52] let me re explain [20:52] why would you leave it installed if you're not doing work on the boot sequence? [20:52] i dont care about bootchart speed [20:52] the collector slows down your boot anyway [20:52] i care about having access to a vast array of bootcharts [20:52] why? [20:53] unless you know what you changed between each chart, they're not really helpful [20:53] for example, graphing performance over time [20:53] maybe to identify common problems outside the defaults tested [20:53] but it's not useful [20:53] because you don't know what changed to cause any bootchart changes [20:54] "my boot is faster/slower" kinda of reports are nice [20:54] but not really helpful [20:54] "with ext3 my boot takes 25s, with ext4 my boot takes 21s" are useful [20:54] you only need two charts for that, one before, make the change, then another one after [20:56] well it would at least provide a high level view for people who don't dedicate themselves to the task, and help identify large upward spikes [20:56] presumably you arent testing thnigs that would make it worse [20:57] but that data isn't helpful [20:57] to use a real-world example [20:57] it's like taking your weight every morning [20:57] and making pretty graphs [20:57] and realising you're getting fatter, and identifying spikes [20:57] but then not recording what you're eating, or how much exercise you're doing [20:57] it's no good knowing that there was a 7-day spike when you weighed 5kg more [20:57] if you don't also note down that it's christmas and you stuffed your face [20:58] bootchart is only the measurement of time [20:58] in order for it to be meaningful, we need to know what changes between successive ones [20:58] so they don't identify large upward spikes at all [20:58] worse still, they can be self-propelling [20:58] they're meaningful [20:58] two people can both identify an increase in boot time [20:58] they're just not proscriptive [20:58] and assume they're for the same reasons [20:59] and unfortunately, the chart doesn't tell you they're not [20:59] (we've seen this) [20:59] it tells you there's a problem, not what the problem is [20:59] one person had a legitimate bug [20:59] the other's hard drive was dying [20:59] exactly, and I don't think that it's a good way to detect the problem [20:59] simply logging /proc/uptime at the end of rc.local is as good as anything [20:59] you don't need bootchart for that ;) [20:59] bootchart is a tool for people actually making changes and wanting to see whether they have an effect [21:00] (actually, bootchart is largely a tool for making changes to the readahead profile, but hey) [21:00] you could measure the change in readahead time =/ [21:00] i donno if that would help, readahead is a cache trick with distributed consequences [21:00] doesn't quite work [21:00] but yes, that kind of thing [21:05] Keybuk: so if firefox rendered bootchart svgs correctly in jaunty, is there any reason to continue pngification? [21:07] yes [21:07] I like pngs [21:07] you can view them with zvg [21:07] zgv even [21:08] well, its trivial to enable / disable it, and you can easily convert later ;) [21:08] I'm sorry, but I just don't agree with your use case [21:08] you're complaining because it makes your boot slower [21:08] well, bootchart in general makes your boot slower [21:08] im not [21:08] of course its slower [21:09] so what's the issue? :-) [21:09] it's bigger on disk, throws away potentially valuable information, and in random edge cases, massively delays boot [21:10] err, the svg is much bigger on disk actually [21:10] svgz [21:10] no valuable information is thrown away, the svg is identical [21:11] however the png is much more portably viewable [21:11] (including can be viewed on the console) [21:12] (I'd be interested to see the random edge cases, btw [21:12] https://bugs.launchpad.net/ubuntu/+source/bootchart/+bug/218499 [21:12] and would wager that the process taking the longer time isn't rsvg but is the java one :p) [21:12] Malone bug 218499 in bootchart "after fsck, bootchart -> rsvg-convert makes computer slow" [Low,Confirmed] [21:12] you've seen it already [21:12] right, and that one, it's mostly the java one that takes longer [21:13] rsvg-convert just takes longer too [21:13] so by the time people look, it's that one as well [21:13] and as I say in the bug [21:13] "then uninstall bootchart" [21:15] rtg: and I really must stop lsb-release calling apt-cache === rikai_ is now known as rikai