GUADEC 6 GNOptimization talk and nautilus cache fun
Monday May 30, 2005
I was fortunate to be able to present at last year's GUADEC and learned much at that and the previous GUADEC. I wasn't able to attend this year, but I found time to listen to Robert Love's talk on GNOME optimization. It's great to hear that Rob, Michael, BenM and a few of us Sun guys are interested in improving performance (and therefore, scalability.) In these days of ever increasing CPU clock speed, it's easy to make the mistake of assuming that optimization is obsolete. But as Robert pointed out, disks are still a terrible bottleneck. We shouldn't even take CPU resources for granted. A few thousand unecessary system calls or stats eventually add up to something. And if Moore's observation ever bumps into a physical limit, optimization will become the only way of increasing performane. I'm glad to hear the progress is being made. A few of the suggestions involved features specific to the Linux kernel but the classic problems and solutions, mmaping files, slab allocators, more efficient memory usage, minimizing seek time (thanks MarkM for the gconf patch!)... apply to every platform GNOME runs on, including Solaris.
Towards the end of the talk, Robert talked about the lack of tools. I was like an armchair sports fan, I wanted to shout into the microphone of my JDS laptop, "Hey, this looks like a job for dtrace, or libumem or Solaris pmap!..." Here is an example just for fun. I used Richard McDougall's cache hit ratio dtrace script while opening a directory in nautilus on a machine with a non-infinite amount of physical memory:
Read IOPS /etc/gnome-vfs-2.0/modules/ssl-modules.conf logical 6 /etc/gnome-vfs-2.0/modules/smb-module.conf logical 6 /etc/gnome-vfs-2.0/modules/mapping-modules.conf logical 6 /etc/default/nss logical 6 /etc/gtk-2.0/gdk-pixbuf.loaders logical 8 /usr/share/icons/blueprint/48x48/filesystems/gnome-fs-desktop.png logical 8 /lib/ld.so.1 logical 8 /usr/share/pixmaps/nautilus/text-selection-frame.png logical 8 /usr/openwin/lib/locale/locale.dir logical 8 /dev/../devices/pseudo/clone@0:ptm logical 9 /dev/../devices/pseudo/random@0:urandom logical 9 //usr/share/icons/blueprint/36x36/apps/gnome-spinner.png logical 9 /usr/share/mime-info/staroffice.keys logical 9 /usr/openwin/lib/X11/fonts/TrueType/fonts.cache-1 logical 11 /usr/share/themes/blueprint/gtk-2.0/gtkrc logical 16 /home/bnitz/.ICEauthority logical 18 /etc/netconfig logical 18 /usr/openwin/lib/locale/locale.alias logical 22 /usr/share/mime-info/gnome-vfs.keys physical 64 /usr/share/mime-info/gnome-vfs.keys logical 187 Read Bandwidth /home/bnitz/.Xauthority-n logical 49152 /usr/lib/charset.alias logical 49152 /usr/share/gnome-2.0/ui/nautilus-directory-view-ui.xml logical 49152 /var/tmp/gconfd-bnitz/lock/0t1117472298ut739439u129650p6993r17830k134508996 logical 49152 /usr/share/icons/blueprint/48x48/apps/gnome-system.png logical 49152 /usr/share/mime/globs logical 49152 /usr/share/mime/magic logical 49152 /usr/share/themes/blueprint/gtk-2.0/gtkrc logical 64000 /usr/openwin/lib/locale/locale.dir logical 65536 /usr/share/icons/blueprint/48x48/filesystems/gnome-fs-desktop.png logical 65536 /usr/share/pixmaps/nautilus/text-selection-frame.png logical 65536 /usr/share/mime-info/staroffice.keys logical 73728 //usr/share/icons/blueprint/36x36/apps/gnome-spinner.png logical 73728 /home/bnitz/Desktop/star.desktop logical 81920 /home/bnitz/Desktop/starthere.desktop logical 81920 /usr/openwin/lib/X11/fonts/TrueType/fonts.cache-1 logical 90112 /home/bnitz/.ICEauthority logical 147456 /usr/openwin/lib/locale/locale.alias logical 180224 /usr/share/mime-info/gnome-vfs.keys physical 598016 /usr/share/mime-info/gnome-vfs.keys logical 1531904 Read IOPS /dev/../devices/pseudo/clone@0:ptm logical 6 Read Bandwidth /dev/../devices/pseudo/clone@0:ptm logical 7663
In this example, most files have logical counts with no corresponding physical counts, it looks like we hit the cache. But it looks like gnome-vfs.keys only has about a 74% cache read and 71% cache bandwith hit rate. It is also possible to add a few ustack(n) commands to the script in order to see where we are in the code when this physical I/O is taking place.
|
|
|
|
