El mié, 11-04-2007 a las 23:56 +0100, Chris Ball escribió: > No, systemtap is kernelspace only right now. Dtrace/Solaris is doing > much better than Linux for that kind of userspace probing.
Yeah :( [Insert rant about why a GPLed Solaris would make adding this to Linux so much easier.] > Also, here's a set of useful systemtap scripts/examples: > > http://sourceware.org/systemtap/wiki/WarStories Wow, this is really fucking cool! It looks like Systemtap has matured a lot since the last time I looked at it :) I'll try to make some time to get it going on my box. Still the hard thing about optimizing login time is knowing where to look. Systemtap and strace can tell you things like "this process opened 1000 files", but so what? If they are absolutely needed and you preload them, that will be fast. It is harder to know if they are actually needed. And there's just so much data in a global trace that it's really hard to find the candidates for optimization. So, the approach I've been taking is to look at GNOME's basic shell programs one by one (Nautilus and gnome-session so far) and see where *they* get slow. You immediately run into things that the program itself could do better (e.g. getting rid of excess work like nautilus-cd-burner launching daemons during nautilus startup). With a bit more poking, you start seeing things that cannot be fixed within the program, but that depend on interactions with others --- for example, the bonobo-activation-server thing that needed to be threaded. Maybe some stupid program (the panel?) is taking too long to register back with gnome-session, thus blocking the startup of programs with lower priority (we don't know that yet). One *very* productive thing you could do with Systemtap (I hope) is to see 1) when programs need to access disk blocks; 2) when the kernel actually reads those blocks. Michael Meeks thinks the kernel may be doing stupid things with respect to I/O scheduling. If systemtap could give you stack traces of the processes, then we could ask it for this: - Give me a stack trace every time a process goes to sleep on a socket/pipe read or write, or select()/poll(), and tell me when they wake up. I don't care about sleeping on a read() from a file or a stat(), since we can mostly optimize those away with some careful preloading. I do care when programs get chatty with each other (gconf roundtrips, any D-bus crap, X server roundtrips, network access *shudder*, etc.). Federico _______________________________________________ Performance-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/performance-list
