IBM Linux Technology Center: Several priorities for improving Linux

IBM’s Linux Technology Center is a virtual organization. It includes
about 250 people in several locations around the globe. Team members
can be found outside the United States in Japan, Israel, Australia,
India, England, and Germany. Nearly a hundred engineers are located in IBM’s
sprawling campus in Austin, Texas. I recently had the opportunity to
visit with Sheila Harnett, co-founder of the LTC, and currently its
technical lead, at her office in north Austin.

Harnett is neither a manager (she reports to IBM v.p. Dan Frye, who is
the director of the LTC), nor a full-time kernel hacker. Most of her
efforts these days come in the form of the coordination of efforts of software
engineers on the team. But don’t mistake her for a paper shuffler.
Last year she was awarded the title of Distinguished Engineer, the second
highest honor IBM awards for technical excellence. That for her work
on a number of operating systems since joining IBM nine years ago. She came
to Austin from Boca Raton in the mid-’90s, along with other remnants of
the core OS/2 development team. For the past three years, she has worked on
Linux exclusively.

In her current role, she is intimately familiar with all the work going
on in the LTC and the perfect person to ask what’s happening there. She
spent a good half hour answering that question, leaping from system
architectures to sophisticated protocols to kernel debugging as if she
were a chef discussing favorite recipes. It doesn’t take long in
conversation with Harnett to see the quickness of mind and breadth of
knowledge that earned her the title of Distinguished Engineer.

So what is going on at the LTC these days, and particularly in that
part of the LTC located in Austin? The short answer is plenty. And that
answer includes work in such key areas of Linux as scalability,
printing, availability, internationalization, testing, and standardization.

It’s a given that people working in Open Source are working on areas
that interest them. I came into the interview thinking that meant that the
LTC would be focused above all else on improving Linux’s scalability on its
mainframe eServers. Not so.

I ask Harnett what the LTC’s top priority was. She answers:
“Actually, it is really hard for me to pin something as the top priority. Because
I think incremental improvement is what is important … We are actually
trying to incrementally raise the bar across the board … When analysts
like D. H. Brown compare Linux to other commercial Unixes, you know
they identify the standard ‘ilities.’ You know: reliability, serviceability,
availability, manageability. What is important is to nudge Linux up in
all of those categories.”

Scalability, of course, is one of those categories. Harnett says Linux performs well today on four-way SMP boxes, but the LTC is working on contributions to make it perform equally as well on eight-way machines. She said, “That might mean changes to the scheduler. Or changes in the I/O subsystem … making a finer granularity locking throughout the kernel.”

I ask how the LTC responded to Linus Torvald’s insistence that making
Linux scale better at the high end not have a negative impact on those
who use it on decidedly low-end, uniprocessor boxes. She replies, “It’s not
an issue, but it certainly is a consideration in how we implement the
improvements that we want to make.” She adds that “a case in point is we
have a patch for the scheduler … such that there is a queue for every
processor, and the ultimate result is that you get better/less lock
contention in trying to access the run list.”

After submitting the patch, Torvalds questioned the need for a special
case. “So we have reworked the patch and we’re submitting it. We are
definitely trying to work from the design point, work to the design point, that
has been established by the kernel maintainers, or, any of the component
maintainers. That’s really important,” Harnett concludes.

Another area where IBM’s views do not dovetail exactly with those of
the kernel maintainers is on the issue of kernel debuggers. Harnett says
it probably does not make sense to continue the debate over getting a
debugger into the kernel source. But she notes that IBM still believes
it can make an important contribution to Linux in this area. So IBM works
with its distribution partners (Turbolinux, SuSE, and Red Hat) to
provide kernel debugging tools in the realm of enterprise support. That’s an
area where IBM’s enterprise customers have come to expect such
utilities to be available.

As a matter of fact, the LTC in Austin provides Level 3 support on the
Linux kernel for IBM’s customers. Level 3 support is defined as
support by those who have their hands on the code. Harnett says, “That is an
alternate way to add value, but our preference would be to have all of
our contributions incorporated (into the kernel).”

Other contributions that have come from the LTC thus far include JFS,
a journaling file system, the Omni print driver project, which provides
support for more than 300 different printers, and the work done on the Linux
Standards Base and Free Standards Group.

Still evolving from within the LTC are projects to create stress and
regression testing, test cases for LSB compliance, tests for certification, a new telephony related protocol called the SCTP, or Screen Control Transmission Protocol. According to Harnett, SCTP “allows the aggregation of bands. If you have a host that is multi-homed, that has multiple IP addresses, for example, it will be able to fail over from
one to the other, and it is inherent in the protocol.”

Obviously, there is more going on at the LTC than I can cover in this
article. They are a very busy group with their hands on a lot of far-flung open source projects. The link below is a good starting point to learn more about what the LTC is up to.

I left the interview with the impression that the LTC is not your
father’s IBM. The tools are different, for one thing. Harnett explains that the
LTC routinely uses CVS for source code management in order to more
easily deal with remote engineers. Ditto for the use of IRC for communications.
Harnett notes that in a traditional environment, “you can get up and
walk down the hall to talk to developers, and then that will attract a
couple of other people, and you have a lot of meaningful conversations. When
you have a global organization. you can do that with the IRC channels.”

Resources: IBM LTC Projects.