Re: Login time

[Federico Mena Quintero <federico ximian com>]

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