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.
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
We're continuing to reach out to potential sponsors.
Work continues on long-term projects.
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
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.
announced a grant
work on NFSv4 on Linux, in cooperation with Sun Microsystems.
snapshot of NFSv4 for Linux 2.2.14
is now available.
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.
- 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.
Niels and Chuck completed two papers to be presented in
October at the Atlanta Linux Symposium.
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
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
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
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
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: email@example.com, firstname.lastname@example.org
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: email@example.com
> 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
A more complete
for this mail is also available.
If you have comments or suggestions, email
linux-scalability @ citi.umich.edu