=== Tim-away is now known as TimStarling
CarlFK1this is only a little OT: where can I put a script to load netconsole?06:03
=== asac_ is now known as asac
=== asac_ is now known as asac
=== mcasadevall is now known as NCommander
=== mcasadevall is now known as NCommander
CarlFK1smb_tp: remember my "boot pauses" https://bugs.edge.launchpad.net/linux/+bug/254668 14:25
ubot3Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] 14:25
apwrtg, did you have a chance to look at the lpia trees i pushed yesterday?14:26
CarlFK1wondering if it is related to  "Tainted: P   M "   https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/31722714:26
ubot3Malone bug 317227 in linux "skb_over_panic skbuff.c:128 invalid opcode: 0000 [1] SMP " [Undecided,New] 14:26
CarlFK1or there is anything related, given you looked at that boxes dmesg more than once 14:27
rtgapw: its on my todo list for this morning.14:32
apwno worries14:32
smb_tpCarlFK1, 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 link14:33
CarlFK1smb_tp: ill try a jaunty kernel and comment both of those bugs 14:42
smb_tpCarlFK1, Ok, I am not really convinced they are tied together but thats just by quickly looking upon it14:43
rtgsmb_tp: 2.6.27 stable updates pushed14:45
smb_tprtg, Ok, thanks14:45
smb_tprtg, that was stable update to -11, right?14:46
smb_tpDoh, I meant to say14:46
rtgnot to be confused with -11 :)14:47
smb_tpyeah, thought of it the moment I hit enter14:47
smb_tpThe upload of this will have to wait until we got the current one to -updates14:48
CarlFK1smb_tp: fixed the pause - yay14:55
CarlFK1"failed to start X"... not so yay.14:55
smb_tpCarlFK1, So rather yayno. First is good, now I only would have to find which of the zillion changes this was.14:56
Keybukand I stress that this isn't final20:39
Keybukwith just kernel and udev updates, it looks like jaunty takes 10s less time to boot than intrepid already20:39
Keybuk(no switching to ext4 or anything like that)20:39
rtgI've read similar anecdotal evidence. Is that with readahead?20:40
Keybuksame readahead as intrepid20:40
KeybukI did reprofile it to make sure20:40
Keybukbefore both20:40
Keybukso that shouldn't effect the numbers20:40
Keybukgrub to full login is now 61s20:41
rtghuh, I didn't know we were doing readahead. Is that part of initramfs?20:41
Keybukit's part of the normal system booy20:41
Keybukhas been since, err, hoary20:42
KeybukI'm pretty sure it was Mataro we put that in, the food still haunts my memories20:42
Keybukso it wasn't warty20:42
rtgdrat, I was hoping readahead would get us the next 10 second win.20:42
Keybuksorting out readahead might buy us more20:43
Keybukbut this is SSD20:43
Keybukreadahead counts for less than 1s of the boot to read in the entire profile20:44
rtgI'm working on LRM boot time link. that ought to buy us 2-4 secs20:44
pwnguinone thing ive noticed is that boot time degrades over time =/20:44
Keybukswitching 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 required20:44
Keybukpwnguin: sure, because your readahead profile gets increasingly out of date20:44
Keybukso you need to load more from disk20:44
rtgKeybuk: have you messed with ext4?20:44
pwnguinKeybuk: there's also the matter of fragmentation20:45
Keybukpwnguin: ext* are largely self-defragmenting20:46
Keybukrtg: no, noet yet20:46
Keybukmy next task is to sort out module-init-tools20:46
KeybukI'm hoping for another couple of seconds there20:46
pwnguinKeybuk: and yet, i have documented proof that super duper hack involving tar retrieves a few seconds20:46
Keybukthen sort out the hardware clock and console setup (on the sprint agenda), I'm hoping *that's* another couple of seconds20:46
rtga few sends here, a few seconds there, ....20:47
Keybukpwnguin: 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
pwnguinit could be that the fs groups writes together20:47
Keybukthere's a sleep in procps I'm going to uncover20:47
pwnguinso theres fewer seeks20:47
Keybukthat's almost 2s20:47
rtgthats an odd place for a sleep20:47
pwnguinKeybuk: what do you think about removing the png-ification on bootchart, and leaving it as svg?20:47
Keybukrtg: I know20:47
Keybukpwnguin: SVGs are a pain20:47
Keybukname me a program that can view them20:48
Keybukinkscape can't view them, it can edit them20:48
Keybukfirefox can't view them last time I looked unless they're embeded in html20:48
* Keybuk doesn't understand why people mind the pngification20:48
pwnguinit basically defeats datamining20:49
Keybukrtg: well, with all the bits and pieces everywhere, including ext4 ... I'm hoping for X in 15s for jaunty20:49
Keybukpwnguin: I don't follow? bootchart doesn't include itself in its own chart ;)20:49
rtgnow if we could speed up that pig GDM startup20:49
Keybukrtg: this is rather less than what I thought we could get - so I'm really happy20:49
Keybukyou guys have done great work20:50
Keybukkernel accounts for roughly half of that improvement from what I can tell20:50
pwnguinKeybuk: imagine being able to graph the bootchart over time20:50
Keybukpwnguin: personally I disable stop-bootchart and run it by hand once I get to the logged in session anyway20:50
Keybukpwnguin: again, irrelevant, since bootchart doesn't include itself20:51
Keybukyou start generating the png at the point you've stopped collecting data20:51
pwnguinim vastly confused20:51
Keybukbootchart generates a chart of your boot20:51
Keybukat some point, it decides to stop collecting data20:51
Keybukthat's when it generates the chart20:51
Keybukso the time to generate the chart is irrelevant to the length of time it takes to boot20:51
pwnguinand then it writes to $version-$date-$uid20:51
Keybuknow, some people install bootchart20:52
Keybukand leave it installed20:52
pwnguini agree, but i never said anything about bootchart itself20:52
Keybukand complain that it slows down login or something, because it's generating the png20:52
Keybukbut well20:52
Keybukthat's silly20:52
pwnguinlet me re explain20:52
Keybukwhy would you leave it installed if you're not doing work on the boot sequence?20:52
pwnguini dont care about bootchart speed20:52
Keybukthe collector slows down your boot anyway20:52
pwnguini care about having access to a vast array of bootcharts20:52
Keybukunless you know what you changed between each chart, they're not really helpful20:53
pwnguinfor example, graphing performance over time20:53
pwnguinmaybe to identify common problems outside the defaults tested20:53
Keybukbut it's not useful20:53
Keybukbecause you don't know what changed to cause any bootchart changes20:53
Keybuk"my boot is faster/slower" kinda of reports are nice20:54
Keybukbut not really helpful20:54
Keybuk"with ext3 my boot takes 25s, with ext4 my boot takes 21s" are useful20:54
Keybukyou only need two charts for that, one before, make the change, then another one after20:54
pwnguinwell it would at least provide a high level view for people who don't dedicate themselves to the task, and help identify large upward spikes20:56
pwnguinpresumably you arent testing thnigs that would make it worse20:56
Keybukbut that data isn't helpful20:57
Keybukto use a real-world example20:57
Keybukit's like taking your weight every morning20:57
Keybukand making pretty graphs20:57
Keybukand realising you're getting fatter, and identifying spikes20:57
Keybukbut then not recording what you're eating, or how much exercise you're doing20:57
Keybukit's no good knowing that there was a 7-day spike when you weighed 5kg more20:57
Keybukif you don't also note down that it's christmas and you stuffed your face20:57
Keybukbootchart is only the measurement of time20:58
Keybukin order for it to be meaningful, we need to know what changes between successive ones20:58
Keybukso they don't identify large upward spikes at all20:58
Keybukworse still, they can be self-propelling20:58
pwnguinthey're meaningful20:58
Keybuktwo people can both identify an increase in boot time20:58
pwnguinthey're just not proscriptive20:58
Keybukand assume they're for the same reasons20:58
Keybukand unfortunately, the chart doesn't tell you they're not20:59
Keybuk(we've seen this)20:59
pwnguinit tells you there's a problem, not what the problem is20:59
Keybukone person had a legitimate bug20:59
Keybukthe other's hard drive was dying20:59
Keybukexactly, and I don't think that it's a good way to detect the problem20:59
Keybuksimply logging /proc/uptime at the end of rc.local is as good as anything20:59
Keybukyou don't need bootchart for that ;)20:59
Keybukbootchart is a tool for people actually making changes and wanting to see whether they have an effect20:59
Keybuk(actually, bootchart is largely a tool for making changes to the readahead profile, but hey)21:00
pwnguinyou could measure the change in readahead time =/21:00
pwnguini donno if that would help, readahead is a cache trick with distributed consequences21:00
Keybukdoesn't quite work21:00
Keybukbut yes, that kind of thing21:00
pwnguinKeybuk: so if firefox rendered bootchart svgs correctly in jaunty, is there any reason to continue pngification?21:05
KeybukI like pngs21:07
Keybukyou can view them with zvg21:07
Keybukzgv even21:07
pwnguinwell, its trivial to enable / disable it, and you can easily convert later ;)21:08
KeybukI'm sorry, but I just don't agree with your use case21:08
Keybukyou're complaining because it makes your boot slower21:08
Keybukwell, bootchart in general makes your boot slower21:08
pwnguinim not21:08
pwnguinof course its slower21:08
Keybukso what's the issue? :-)21:09
pwnguinit's bigger on disk, throws away potentially valuable information, and in random edge cases, massively delays boot21:09
Keybukerr, the svg is much bigger on disk actually21:10
Keybukno valuable information is thrown away, the svg is identical21:10
Keybukhowever the png is much more portably viewable21:11
Keybuk(including can be viewed on the console)21:11
Keybuk(I'd be interested to see the random edge cases, btw21:12
Keybuk and would wager that the process taking the longer time isn't rsvg but is the java one :p)21:12
ubot3Malone bug 218499 in bootchart "after fsck, bootchart -> rsvg-convert makes computer slow" [Low,Confirmed] 21:12
pwnguinyou've seen it already21:12
Keybukright, and that one, it's mostly the java one that takes longer21:12
Keybukrsvg-convert just takes longer too21:13
Keybukso by the time people look, it's that one as well21:13
Keybukand as I say in the bug21:13
Keybuk"then uninstall bootchart"21:13
Keybukrtg: and I really must stop lsb-release calling apt-cache21:15
=== rikai_ is now known as rikai

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!