2001 Linux Symposium

bird of a feather sessions


Working Groups

High Availability

One of the most commonly identified features which is felt to be necessary for Linux's success is clustering, both for High Availability or High Performance Computing.

As befits the importance of this capability, several proprietary and open source projects have been created. These projects were created independantly for different reasons, most notably that they were originally running on a single specific platform.

However, this has changed. Many of these projects have been ported to Linux by now, and some proprietary ones even been made open source in the process.

Much of this capability is part of the infrastructure an operating system platform provides. While all of the solutions can be divided into components which provide basically the same functionality - though optimised for specific applications - the interfaces are quite widly different, making it hard to implement an application requiring cluster services portably across this infrastructure.

The Linux HA working group session's main focus this year will be to work on defining a path to an Open Clustering Framework which will allow us to overcome these difficulties.

This will allow the developers to implement their applications in a portable manner, while allowing the different open source projects and vendors to focus on their specific area of expertise.

The first steps of this process are:

A) Agree on the main goals of such a clustering framework.

A very well thought out proposal is Alan Robertson's paper "An Open Framework for Clustering" (http://www.linux-ha.org/framework/). B) Agree on the further steps necessary to achieve these goals. Obvious steps are:

  1. Assess currently avaible solutions for their viability under these goals.
  2. Identify components. Functionality provided, features, scope, communication paths
    between components etc.
    (Components which readily come to mind are membership services, reset services, distributed lock managers, application plugins for switch over clustering, group communication services etc)
  3. Design APIs.
  4. Agree on the above.
  5. Figure out how to rework the current situation into components of this framework. Which parts can be reused, what has to be reimplemented or even written from scratch.
  6. Implement the ideas above.
  7. World domination.
C) Agree on how to proceed.

A proposal would be that we create an active discussion on the linux-cluster mailing list and that we adopt the RFC model for papers, ideas, proposals and of course API and protocol definitions and form a permanent working group.

Four months after OLS at Linux Kongress 2001 in Enschede/Netherlands, we have the opportunity to meet again for a 3 day working group session and discuss our findings in detail. (This is step 4 in the above list ;-) It is felt that 4 months is a good time for this follow-up meeting.

In Enschede, we will have enough time to discuss different proposals and agree on how to proceed further.

We will use the first half of the session to present the above in more detail, and spend the second half in a heated discussion.

If you are interested in presenting your thoughts on the above three points, please contact Lars Marowsky-Bree .

You should attend if developing for clusters of any kind is of at any interest to you. Your input is appreciated.

Memory Management

The linux memory management working group intends to discuss the following topics related to 2.6 improvements in the MM area:
  • Identify general goals for MM, e.g. upcoming physical memory sizes, embedded constraints, sparse memory addressing, SMP scalability, NUMA systems, important interactions of MM with other subsystems (e.g. buf cache & filesystems, swapping, etc.)
  • Identify areas where the current MM subsystem does well (e.g. "don't break what's working")
  • Identify areas where the current MM subsystem does NOT do well, or fails to meet the identified goals
  • Identify current patches which attempt to improve the MM subsystem that should be given further consideration
  • Discuss whether the MM architecture needs any substantive changes to meet the identified goals
  • Discuss any other ongoing or proposed development in the MM subsystem.

    NUMA Working Group

    The NUMA Working Group's goal is to run Linux efficiently on NUMA hardware. This is a follow-on meeting to the March 26th meeting in Chicago (see lse.sourceforge.net/numa for more details) and at the 2.5 Developers Summit. In the meantime, discussions have been progressing on the lse-tech mailing list at lse.sourceforge.net.

    "NUMA" stands for "non-uniform memory architecture", and is one technique for building larger shared-memory machines out of smaller ones. Again, please see the web site and the sites it references for more details.

    Thanx, Paul

    Bird of a Feather Sessions

    Ideal Workloads for Measuring Typical Real-World Linux Environments?

    Discuss in a round-table format various performance workloads, pros and cons and appropriateness to actual typical activity from departmental to enterpriseservers. Are Linux workloads typically IO intensive? How do we measure the benefits of performance improvements such as asynchronous IO? Or, are they memory/cache intensive? Or, is TCP/IP the only thing worth testing? How many actualy shmgets does a typical user perform? This session is intended as exploratory, covering both popular and obscure workloads. Realizing that this is an ongoing and dynamic topic, this is intended as a "checkpoint" of what existing workloads are ideal for testing current and eminent versions (and pre-versions and patches) of Linux 2.4+.

    Ruth Forester

    Infiniband on Linux

    The organizer is the InfiniBand(sm) lead at Red Hat. He would like to meet people who do the actual work implementing the specification on Linux and exchange as much information as our loathsome NDAs allow.

    For those who visit the BOF for educational purposes a short message will be given and a questions answered.

    Pete Zaitcev

  • © 2000, 2001 Linux Symposium.  All Rights Reserved.