| |||||||||
|
Summary
The major focus of the first few months has been to create structure and scope for the project, and to begin tackling the learning curve. We've begun building our connections to Netscape staff and to major Linux developers. Stage one of the project workscope has begun.Milestones
- Chuck drafted a project work scope based on papers by Niels and Naomaru, and made it available at CITI and Netscape for review. This document outlines a road-map for this project, its mission, and milestones we expect to encounter. It has been through two review iterations, and is fairly close to completion.
- Dan and Mahesh promised working versions of their Linux ports soon after the November meeting. CITI is waiting for the new ports.
- Niels, Chuck, and Peter met with Netscape server developers during the first week of November to discuss work scope, project deliverables, server performance issues, and Linux server product markets. Chuck will visit Mountain View again in eary February 1999.
- Chuck and Niels have subscribed to Linux community mailing lists, and have been in contact with several developers to begin discussing our work.
- Peter visited with members of Stichting NLNet to discuss additional project funding. Stichting NLNet is interested and seems willing to provide some hardware capital. Chuck is composing a funding request; Peter plans to follow up in 1Q99.
- Niels developed a patch to improve scalability of the kernel's file descriptor allocation routine, based on Gaurav Banga's two-level bitmap idea. See below for some graphs that show the improvement. Niels also developed a patch to make the poll() system call scalable. We're working on getting these patches included in Linux 2.3.x.
- Chuck ported SPEC's SDM benchmark to Linux. The SDM benchmark creates a controlled thread- and I/O-intensive workload. We'll use it to study the effects of heavy workloads on OS subsystems. Chuck has also worked with bonnie, lmbench, and httperf to assess their suitability for the project. Chuck will explore WebStone and SPEC's Web96 benchmark next, while waiting for test harness hardware and software.
- During the week before the Christmas holiday, the research contract between Netscape and the U-M was finally executed. Officially the project begins January 5, 1999.
- Chuck reviewed the C library's memory allocation algorithms to assess their ability to perform well in a multithreaded, multiprocessing environment. The good news is that both libc5 and glibc2 use the ptmalloc implementation, which is designed to work well for multithreaded environments, and is dynamically tunable. We will need to find a good way to measure malloc() performance.
- There is some concern about mmap() performance on Linux. Recent efforts have greatly improved VM performance in the 2.1.x (and thus 2.2.0) kernels; this work involved adding clustering and limited read-ahead/read-behind to swapping and paging. Kernel developers believe that applications doing sequential I/O should use read(), while random access is best done with mmap() and scatter-gather techniques, which do less read-ahead. There is also some question about how exactly to measure mmap() performance; that is, what exactly do the lmbench numbers tell us about mmap() performance? Do they tell us enough? Project work continues in this area.
Challenges
Netscape's server developers have spent considerable effort analyzing and architecting a threading model for network servers. This threading model works well under Windows NT, but none of the Unix-based platforms support it efficiently. Our developers are interested in having Linux support Windows NT-style thread dispatching and asynchronous/queued I/O programming interfaces because they are clean and are known to perform well. Linux builds on POSIX standards, which rely heavily on signals and POSIX threads, and are not directly compatible with Windows NT programming constructs. There is fear that the Linux model won't perform well, and will be difficult to use because of the unknowns involved in mixing signals and threads. Linux kernel developers want to stay with standard interfaces, but have agreed to consider a "shared signal queue" model to help support Netscape's architecture of queued I/O and event-driven thread dispatching. A shared signal queue may or may not meet the performance and programming ease requirements set by server developers.It is important for us to understand that the forces driving the evolution of Linux are different than those driving commercially-developed operating systems. While market forces influence a commercial operating system's feature set, the Linux feature set is determined by what the developers believe is right, based on their desires to have a high-performance standards-based operating system. Since they are not paid for their work, they are not attracted by calls for support of features that may increase marketability, or that may provide support for other commercial software. In other words, they do not work on Linux for customers, but for themselves, for aesthetic reasons. Therefore, if CITI and Netscape wish to influence the design and implementation of Linux, we must get involved with their process, in order to prove the value of our involvement because we have good ideas, and because we have faith in, and respect for, open source. Our involvement needs to take the form of providing source code, patches, and especially detailed benchmark results that back up our good ideas and demonstrate our value to Linux.
Towards that end, the Linux Scalability Project can provide some focused effort addressing specific performance and scalability problems in Linux. In addition to this effort, Netscape can also advance its enterprise Linux agenda by continuing to provide a wide range of support for enterprise Linux. We have begun to make meaningful contributions to the Linux source stream, but there is a high hurdle to surmount before our contributions are fully accepted into Linux.
Performance graphs
If you have comments or suggestions, email linux-scalability@citi.umich.edu
 |
|
 |
