Linux Scalability Project Status report for July and August, 2000

Linux Scalability Project

Status report for July and August, 2000

Center for Information Technology Integration
School of Information at the University of Michigan

The primary goal of this research is to improve the scalability and robustness of the Linux operating system to support greater network server workloads more reliably. We are specifically interested in single-system scalability, performance, and reliability of network server infrastructure products running on Linux, such as LDAP directory servers, IMAP electronic mail servers, and web servers, among others.

Summary

We're continuing to work with vendors such as Sun and IBM on their Linux scalability issues. We've provided several significant modifications to the Linux kernel. We attended the 2000 Usenix technical conference, and presented three papers. We'll present papers at the upcoming Atlanta Linux Symposium. We're continuing to reach out to potential sponsors. Work continues on long-term projects.

Milestones

Stephen Molloy spent his summer interning at the Austin IBM lab. Stephen is continuing earlier efforts to improve the kernel scheduler in Linux so that it scales in the number of active threads. He reports that his scheduler now runs without hanging or crashing on hardware with more than two processors, and beats the original Linux scheduler in tests involving many threads running in a Java virtual machine.
Network Appliance announced a grant supporting continued work on NFSv4 on Linux, in cooperation with Sun Microsystems. A snapshot of NFSv4 for Linux 2.2.14 is now available. This version:
- passes the 9 basic connectathon tests
- dos share locks implemented, byte-range locks almost done
- rudimentary delegation - semantics correct, no client side cache yet.
- most of the protocol coded
- security - rpcgss_sec kerberos5 mutual authentication, security negotiation per exported subtree.
Andy stresses this is the most mature NFSv4 client and server available. Full spec rpcsec_gss is now available at the user level. CITI's OpenBSD port now has a client that supports mount, read, write ls, cd, and pwd.
Niels and Chuck completed two papers to be presented in October at the Atlanta Linux Symposium. See the USENIX events calendar for more information. The papers are also available as CITI technical reports.
The high-performance web server team at HP has studied Niels' /dev/poll implementation, and reports a 3x performance improvement for their application over regular poll(). We are preparing a version of this work for inclusion in the 2.5 Linux kernel.
Chuck continues analyzing and improving phhttpd, a POSIX RT signals-based server written by Zach Brown. This work will provide a better picture of performance, scalability, and usability issues surrounding network server applications that build their event core using POSIX RT signals. Zach has accepted Chuck's patches into the phhttpd source distribution.
Work continues on improving mmap() performance. A nascent freelist implementation exists to find the best way to incorporate an address space freelist into the Linux kernel memory manager.
Chuck is assembling a directory server test harness. A Solaris workstation borrowed from U-M's Login Service will help size the hardware requirements while we gain experience with Mindcraft's DirectoryMark benchmark software.
Andy attended the Ottawa Linux Symposium for a day to discuss NFSv4 integration with the mainline Linux distribution. As a result of CITI's work on NFSv4 on Linux, VALinux and Network Appliance are interested in funding an longer-term NFS performance and scalability project at CITI.
Chuck met with Will Morris, Stephen Borcich, Mark Wahl, and Hal Jespersen in mid August to discuss the future of the Linux Scalability Project. Greg Lavender, head of the Directory Server effort at iPlanet, is building an advanced server technology research group that might have some convergence with the LSP. A meeting is planned for early October where Peter, Chuck, and Greg will discuss the possibilities.
We continue to pursue research relationships with Red Hat Software, Silicon Graphics Incorporated, VALinux, and Network Appliance.

Linux development: open or closed?

This recently appeared on the linux-kernel mailing list. Eric Raymond is arguably the most visible open source advocate on the planet, and David S. Miller is a long-time Linux kernel developer who resides in the "inner circle."

Date: Sat, 12 Aug 2000 18:58:11 -0400
From: Eric S. Raymond 
To: Timothy Knox 
Cc: kmfav@yahoo.com, linux-kernel@vger.rutgers.edu
Subject: Re: Fwd: Closed-door development

Timothy Knox :
> I don't know if somebody already forwarded this to you, but if not, here
> it is...
> 
> ---------------- Begin Forwarded Message ----------------
> Subject: Closed-door development
> Date Sent: Friday, 11 August 2000 11.24
> From: KMF AV 
> To: linux-kernel@vger.rutgers.edu
     :
> Answering almost with Raymond's own words: can it be
> that we hackers like to think that the success of our
> software is due to a genial, new way of development
> that we have come up with ourselves? Is it truly so?
> CatB is not a software engineering essay. It is an
> anthropological study. However, it contains material
> about the bazaar, the hackers' way of doing software
> engineering. Central traits to the bazaar is the open
> process, the freedom to do with the code what each
> individual developer wants, and a high degree of
> cooperation. Raymond mentions Linux as an archetypal
> bazaar, yet in a letter to the author David Miller, a
> central Linux developer, writes:
> 
> Date: Tue, 5 Oct 1999 18:40:06 +0200 (CEST)
> From: David S. Miller
>  
>> is it so that you core Linux kernel developers are doing much of the
>> discussing and planning outside of the Linux kernel mailinglist?
> 
> It is true to a large extent, and in my opinion it's
> the gem that keeps us at such high productivity rates.
> 
> It's a surefire method by which us core developers can
> obtain the best signal to noise ratio. Discussions happen
> more efficiently and productively when you know you're talking to
> someone with a clue and you don't get barraged with responses from folks
> who are perhaps not so clueful and not so weathered on the topic as
> the core  developers. 
>
[End of excerpt, not marked in the quoted original.]

> I.e. there is a mismatch between the map and the
> terrain, the map here being Raymond's bazaar and the
> terrain being how things work in the real world. While
> there is an open forum, areas for community building,
> the development in itself is being done in a closed
> fashion. The results, i.e. the source code, is up for
> public review, so the product itself is still open.
> The process, however, is a closed one, and it is the
> process more than the product that Raymond emphasize
> as the bazaar model.

Bzzzzzt!  Wrong!  Thank you for playing.

Many bazaar projects have inner and outer circles.  In fact, this
two-tier organization is more typical than not -- when I created
`friends' and `announce' lists for fetchmail I was following widely
established practice.  This simply reflects a natural gradient of
interest and competence and commitment.

It's also the case that the peer-review effect at the heart of Linux's
success uses the brains and eyeballs of the *entire* developer population,
regardless of what concentric circles or cliques they self-organize into.

It's wrong on the facts to say that Linux kernel development is being
done "in a closed fashion" or that lkml is only for community building.
Real design debates do take place there.  Anybody can originate and send a
patch.  And anybody, by displaying sufficient ability and commitment,
can work his or her way into the informal inner circle.

Anybody who thinks this is "closed" has clearly taken too many drugs to 
remember what really closed development is like.
-- 
                Eric S. Raymond

If gun laws in fact worked, the sponsors of this type of legislation
should have no difficulty drawing upon long lists of examples of
criminal acts reduced by such legislation. That they cannot do so
after a century and a half of trying -- that they must sweep under the
rug the southern attempts at gun control in the 1870-1910 period, the
northeastern attempts in the 1920-1939 period, the attempts at both
Federal and State levels in 1965-1976 -- establishes the repeated,
complete and inevitable failure of gun laws to control serious crime.
        -- Senator Orrin Hatch, in a 1982 Senate Report

ESR continues with this next e-mail, published recently on the lwn.net site:

http://lwn.net/2000/0824/a/esr-sharing.php3

A more complete context for this mail is also available.

If you have comments or suggestions, email linux-scalability @ citi.umich.edu