Muli Ben-Yehuda's journal

I’m playing with orkut now, thanks to gby. Leave a comment or email me if you want me to add or invite you and I haven’t yet.

laptop porn. I wonder how well this beastie supports linooks?

Rusty posted a string of hilarious emails from lkml and elsewhere that were shown during the LCA2004 dinner. Recommended reading, provided you’re not drinking anything at the same time…

I gave the first run of the “Intro to Linux Device Drivers” talk yesterday to the study group at work, and today to the students of the Technion’s CS faculty’s Operating Systems course. It went quite well yesterday, with lots of audience participation and excellent feedback afterwards. Today it didn’t go quite as well (much tougher crowd…), but I think the objectives were achieved and they have an idea of what writing a driver entails.

After the talk, I went to the office, feeling rather miserable. Had lunch and then gave up and went home, feeling like I’m about to hurl at any moment. Got home and climbed into bed with James Clavell’s Shogun.

It’s one AM now, and I have a backlog of work stuff to take care of before tomorrow. Let me just put on some music and let the fun begin. No more talks for me in the near future! It’s time to write some free software.

Had one of those days that make me wish I could get better acquainted with every nearby computer, preferably with a chainsaw. I spent 7.5 hours(!) trying to get 2.6.1 to boot on a thinkpad running Fedora Core I with the root file system on an LVM volume. Eventually, it did.

The rest of the day was spent alternatively writing code and slides, for the “Introduction to Linux Device Drivers” talk. I can’t say I’m too thrilled with the way it turned out, but hopefully, it will do. The code, klife-0.02, is available here. It’s does mmap and hooking into the timer interrupt, but the races are abundant. To be cleaned up after I get some sleep (or maybe left as an exercise to the readers ;-))

Quick catchup time:
– da_x announced coLinux which he’s been telling me about for a while now and the reception was terrific. Well done, da_x!
– UML with 2.6 woes (posted earlier) were solved thanks to the nice guys on #uml. Turns out that UML does not play well with exec-shield, which FC1 comes with. Running ‘i386 ./linux …’ instead of plain ‘./linux’ allows it to run. No idea what the i386 utility does yet, but disabling exec-shield seems like a pretty safe bet.
– I could swear there was more I needed to write about, but I can’t remember what.

When writing slides for a talk that includes a lot of code, is it better to accompany each slide of code with a slide of explanation, or just intermingle the explanation with the code, in the form of copious comments? I’m leaning towards the comments form, but I’m open to persuasion either way. What do y’all think?

Interesting talk, gave me a lot of pointers on what to talk and what not to talk about on Wednesday. Lecture slides available here (zippped .ps) and code samples here. Very rough notes available here, to be cleaned up and reposted as time permits.

I am about to head for the Technion to listen to a lecture on developing Windows device drivers. I will give the corresponding lecture on developing Linux device drivers on Wednesday. Impressions and ponderings to appear when I’ll be back.

Paul McKenney, IBM Distinguished Enginneer and Linux Kernel hacker, will be visiting IBM’s Haifa Research Lab next week. He’ll give a talk on “An Analysis of Read-Copy-Update Techniques in Operating System Kernels”, which is open to the public (details will show up here). I’m definitely excited to meet him again!

Abstract:

Although large-scale shared-memory multiprocessing hardware and software reached the mainstream in the past decade, their synchronization mechanisms make use of costly operations that inherently limit both single-CPU performance and shared-memory-multiprocessor scalability. The key problem with these mechanismsis that they do nothing to decrease the intensity of communication required by conventional algorithms, and this high intensity of communication, or tight coupling, in turn requires heavy use of the expensive hardware synchronization mechanisms that impose performance and scalability limitations.

Although there have been some high-performance and highly scalable algorithms developed for some important special cases, such as memory allocation and statistical counters, one would wish for a more general approach. Recently, a wide-ranging set of specific solutions to particular synchronization algorithms have come to light which use a common implementation of some support functions and some design patterns. This set of solutions has been loosely termed “read-copy update” or RCU.

This talk demonstrates the performance problems of previous approaches, and analyzes the use of RCU techniques in earlier operating-system kernels in order to derive the needed design patterns. I used these patterns to architect the implementation and use of RCU in the Linux 2.6 kernel, which was instrumental in improving the performance and scalability over that of the Linux 2.4 kernel. Empirical and analytic techniques are used to analyze the performance and simplicity benefits of RCU.

About the speaker:

Paul McKenney is a Distinguished Engineer in the Storage Software Architecture group and the Linux Technology Center, and is a member of the IBM Academy of Technology. He joined IBM in 2000, working with AIX, Linux, and storage. Prior to that, he worked at Sequent doing SMP and NUMA algorithms. The work described in this talk stems from his work at Sequent and with the Linux 2.6 kernel.

Spent the last couple of hours trying to get UML based on the latest -vanilla kernel (2.6.2-rc1) to compile and boot. It compiles, after taking care of the extable changes, but dies immediately after boot with:

muli@hydra:~/kernel/uml/src$ ./linux debug 
Checking for the skas3 patch in the host...not found 
Checking for /proc/mm...not found 
Segmentation fault 

I’m too tired to deal with this right now. Will wait for tomorrow, or jdike, whichever happens first 😉