Ari Tamches

email: tamches1@yahoo.com

Current Employment:

VMware
Palo Alto, CA

Education:

B.S. Computer Science, University of Maryland-College Park, 1993.
M.S. Computer Sciences, University of Wisconsin-Madison, 1995.
Ph.D. Computer Sciences, University of Wisconsin-Madison, 2001.

Ph.D. dissertation (2001): Fine-Grained Dynamic Instrumentation of Commodity Operating System Kernels.

You can download my dissertation here (215-or-so pages, PDF format).

Here is a brief run-through of the dissertation.

Chapter 1 is the introduction. You can read this if you don't want to read the whole thing.
Chapter 2 discusses related work.
Chapter 3 describes the KernInst architecture. Some of the grittier low-level algorithms are discussed here, such as CFG and live register analysis of the kernel's code.
Chapter 4 discusses splicing and code replacement, KernInst's the two central primitives for dynamic kernel instrumentation. As far as low-level details go, this is probably the primary chapter in the dissertation.
After chapters 3 & 4 have laid down the infrastructure, the second half of the dissertation is able to lighten up somewhat and discuss some real-world uses of the low-level technology. Chapter 5 discusses kernel performance measurement via dynamic instrumentation, and chapter 6 carries on with an OS performance measurement case study.
Chapter 7 is a fun, if seemingly tangential, diversion. I show that in practice, CFG edge counts can be derived from CFG block counts. This conclusion defies graph theory (which tells you that you can calculate CFG block counts from edge counts, but not vice-versa). The restriction still holds in the general case, but in practice, control flow graphs of code are structured such that it is usually possible to precisely calculate edge execution counts of a function, if given all of its basic block execution counts. 99.6% of CFG edge counts can be determined if given basic block counts, and about 97.8% of functions could determine all of their CFG edge counts given their basic block counts.
Chapter 8 discusses a real gee-whiz application of dynamic kernel instrumentation. If we can hot-patch the OS kernel code to collect performance information, can't we also hot-patch the OS kernel code to optimize it on the fly? A complete analysis of this subject would take up several dissertations. Here I try to open the door a bit with one specific optimization: improving the I-cache performance of the kernel as it runs.
Chapter 9 wraps it all up.

Other research papers:

Workshop on Binary Translation (WBT-2001)

pdf file, 10 pages

7-page version (pdf)

Ariel Tamches and Barton P. Miller. Fine-Grained Dynamic Instrumentation of Commodity Operating System Kernels. Third Symposium on Operating Systems Design and Implementation (OSDI), February 1999. (Postscript, Compressed, Gzipped, PDF)

Ariel Tamches and Barton P. Miller. Using Dynamic Kernel Instrumentation for Kernel and Application Tuning. International Journal of High Performance Computing Applications, v. 13 no. 3, Fall 1999. (Postscript, Compressed, Gzipped, PDF)

Research Interests:

My PhD research is focused on KernInst, a tool which turns a completely unmodified, already-running stock commodity operating system kernel (currently, Solaris 7 running on an UltraSPARC cpu) into a dynamic one, by allowing any dynamically generated code to be inserted before almost any instruction in the kernel. This opens up all sorts of avenues for fun, such as profiling, coverage testing, debugging, runtime optimizations, and lots more.

KernInst is a cousin of the Paradyn Parallel Performance Tools.

Click here

current version of Paradyn

KernInst events:

[Although I'm no longer updating this list, KernInst work is ongoing by members of the KernInst group at Wisconsin. KernInst porting loose ends that I did not finish implementing by dissertation time (porting to 64 bit kernels and multiprocessors) have since been completed, with assistance from Alex Mirgorodskii .]

June, 2000: Thanks to funding from Veritas, Alex Mirgorodskii is working on a 64-bit port of KernInst.

June, 2000: Second off-site KernInst demo at Sun Microsystems. An interesting bit of karma occurred here; my slideshow talk via PowerPoint crashed, while a live and rather in-depth demo of KernInst went off without a hitch.

March, 2000: Virtualization added to KernInst; these are performance metrics that instrument the kernel's context switch code to stop and re-start timers to exclude from the timer's total the time spent switched out.

March, 2000: First off-site demo of KernInst at Veritas Software.

December, 1999: KernInst has been ported to UltraSparc/Solaris 7 (32-bit kernel only, for now).

October, 1999: A prerelease version of KernInst is now being used by a few brave off-site industry testers.

March 25, 1999: At "Paradyn Week '99", I gave the first public demo of KernInst to some of our affiliates in research and industry. (More specifically, I demoed kerninstd alongside kperfmon, a program for performance measurement of selected kernel routines.) Much to my pleasure and somewhat to my chagrin, the universal comment seemed to be "I didn't really believe it worked after reading your papers, or after hearing your KernInst talk, but now I do." Gee thanks, I guess :)

February 1999: I gave a KernInst talk at OSDI in New Orleans. Here are the slides (postscript, powerpoint), if you're interested.

July 1998: KernInst paper submitted for publication. It contains a good overview of the technology behind KernInst, fine-grained dynamic instrumentation of unmodified commmodity kernels (I gotta find an acronym for that).

March 1998: I gave a KernInst talk during a Paradyn affiliates meeting. To see a copy of it, click here.

Late 1997: For the first time, I was able to instrument a Solaris kernel function without causing an immediate reboot :)

February 1997: I gave a very preliminary, very short talk to the Paradyn affiliates meeting on a crazy idea I wanted to try called dynamic kernel instrumentation.

Late 1996: My advisor Bart Miller suggested that I investigate dynamic instrumentation on kernels. He said it might be "fun".

Other Interests:

The lowest-level, nastiest parts of operating system kernels.

The rest of operating system kernels.

Turning ugly, slow, bit-rotted pieces of code (whether I wrote it or not) into lean, mean, and maintainable code.

Alpine skiing. Since I moved to California from Wisconsin after getting my Ph.D., my "home hill" has upgraded somewhat, from Cascade Mountain, WI to Squaw Valley, CA. By the way, there is good skiing available in the midwest, if you know where to look. Try Whitecap Mountain, WI and Lutsen, MN, each unfortunately located in the middle of nowhere.

The C++ Programming Language

Blues and classic rock

Disinterests:

Country music

Computerized techno music (I prefer actual human beings playing the rhythm section on actual instruments, a notion which seems alien in today's popular music.)

Fortran

Slow compilers (why, in this day and age, should compiling take more than one second? Compilers should do their work as you type, in the background.)

Here is some other stuff, such as talks I've given in the Operating Systems and Networking Seminar at UW-Madison, or class project papers. I don't know why anyone would want to look at any of this old stuff, but here it is anyway :)

CS 757 paper: Techniques and Tools for Distributed Shared Memory Performance Improvement
[Spring, 1995] (with M. Callaghan)

Talk: Supercomputer Interconnection Networks
[April 19, 1995]

(Ah, the good ole days of the CM-5...)

Talk: The Zebra Striped Network File System
(or, Why You Need a Log-Structured File System if You Use RAID) [Oct 11, 1994]

From my work in the storage industry, I now see why my conclusions in the above talk were all wrong. (You don't need a log-structured file system to get good performance on a striped disk configuration, provided the disks are attached to a server that is being accessed by many clients. Besides a log-structured file system will, over time, cause horrible fragmentation if write operations don't write to entire files.) Still, it was a fun talk.