Class-based Kernel Resource Management (CKRM)

Introduction

The Class-based Kernel Resource Management (CKRM) project seeks to develop Linux kernel mechanisms providing differentiated service to resources such as CPU time, memory pages, I/O and some virtual resources based on user defined groups of tasks called classes. Changes to the primary resource schedulers such as O(1) (Cpu), deadline/CFQ (I/O) and VM page manager (memory) will be explored and developed.

Currently kernel resource management is done in terms of tasks, address spaces and users. Moreover, except for CPU scheduling and outbound network bandwidth, the current Linux kernel differentiates access to resources based on overall system performance. CKRM aims to make the kernel more goal-oriented by allowing system administrators to define classes and the shares of each resource that a class should get. CKRM modifications to the existing kernel schedulers then ensure that each class gets the resource share specified.

A class is a group of Linux tasks, defined by the system administrator, with a common performance goal e.g. all browse queries in an online bookstore could form a "bronze" class while all purchase orders in the same bookstore could be a "gold" class. Both kind of queries need work to be done by several processes with each process requesting resources in user and kernel mode.

CKRM has several uses. First, it allows work to be prioritized at a level that is intuitive e.g gold class order queries getting more resources than bronze class browse queries in the example above. Similarly, single user desktops can define their backup or antivirus check to consume only x% of CPU and y% of disk bandwidth. This is particularly useful when one process can do work on behalf of several classes (e.g. a webserver process).

Second, by providing explicit and quantitative notion of shares, CKRM enables higher-level systems management software better control over a Linux system. Autonomic controllers can be developed which automatically set shares for classes based on the importance of their work. Such adaptive controllers can use per-class resource usage as feedback.

Finally, CKRM can enable better measurement of system usage. Currently it is difficult to attribute resources consumed in kernel mode to a specific piece of work. By accurately measuring resource consumption in both user and kernel mode, CKRM can allow system administrators to make better decisions on hosting a particular application or type of work on a system.

Project Goals

Project Status

20 Apr '06: f-series, with numtasks and CPU controller, posted to lkml.

Jul '05 - Current: Team is busily working on reducing the complexity and codesize

Oct '05: CKRM team releases a new CPU controller

Jul '05: ckrm gets into -mm tree and quickly got off :(

Feb'05: Revised set of patches, based on e16, released on lkml. Feedback from lists being incorporated in followup patches.

27 Sep'04: e16 patches for ckrm framework, cpu and mem controllers released.

4 Aug'04: CKRM ships out as part of SuSE Linux Enterprise Server 9. The version includes the CKRM framework and numtasks and listenaq controllers..

22 Jul'04: Presentation at Ottawa Linux Symposium. Feedback sent out on ckrm-tech.

20 Jul'04: CKRM presented at Kernel Summit. Feedback from kernel developers sent out on ckrm-tech.

14 Jul'04: ckrm-e15 patches released.

16 Jun'04: Released port of CPU controller to E13. Controller does not support limits and hierarchies.

4 May'04: Released complete testing package ckrm-E13-pkg.tar.bz2 and rule-based classification engines.

29 Apr'04: First implementation based on the 26Feb'04 proposal released on ckrm-tech and lkml. It includes the core including a major reorganization using a newly introduced classtypes, the, rcfs interface, a multiple accept queue resource controller for limiting accepting TCP connections and a simple demo resource controller regulating number of forked tasks.

26 Feb'04: Fourth version of high-level design and user API proposed on ckrm-tech and lkml. The new version incorporates the previous proposals on a filesystem interface, hierarchical classes and support for inbound network control besides support for earlier goodies such as a classification engine and CPU,mem & I/O controllers.

24 Feb'04: Release of patch and performance results for a standalone implementation of inbound network control

5 Feb'04 : Filesystem-based API and high-level design using hierarchical classes proposed on ckrm-tech.

30 Jan'04: Third version of CKRM API and high-level design based on system calls and integrating inbound network control proposed on ckrm-tech

25 Nov'03: Release of second version of CKRM core and RBCE. Controller's have not yet been adopted.

24 Sep'03: First version of I/O controller patch released. Patch provides equal instead of proportional bandwidth to classes..

11 Sep'03: Integrated package for testing memory control released

29 Aug'03 : First major code release with separate patches for core API, CPU and memory controllers, classification module and user programs.

25 July'03 : Presentation and BOF at Ottawa Linux Symposium.

23 July'03 : Source code, description of preliminary versions of CPU and memory controllers released on project webpage. Promising results for CPU and memory control.

Documentation

Downloads

All downloads are available from here.

High level Design

Here is the high level design of the f-series implementation.

Resources

The CKRM SF Project page has the standard sourceforge page for the project - currently only the Files section is being used to provide CKRM releases.

Last Updated Dec 1, 2006.

SourceForge.net Logo