CKRM core API

The core patch defines the kernel API for the classification engine and the individual resource controllers. By itself, it provides no functionality and has no performance impact. The kernel API provided by ck-core consists of two parts :

  1. Controller API

    A class-based controller for a resource ##res## (cpu, io, mem or net) has to implement the following functions declared by the core kernel API i.e. a cpu controller must implement ckrm_alloc_cpu_class() through ckrm_cpu_change_class(), an io controller must implement ckrm_alloc_io_class() through ckrm_io_change_class() etc.

    ckrm_alloc_##res##_class(cls) : create a per-resource class

    The class object returned is opaque to the core API and the classification engine. The resource controller can use the globcls pointer to link its per-resource class back to the global class maintained by the classification module.

    ckrm_free_##res##_class(cls) :free per-resource class cls
    ckrm_dflt_##res##_class : return the default class for that controller

    Every controller must create a default class to contain all unclassified tasks.

    ckrm_##res##_set_share(cls,share) : set the resource share of cls

    Units for the share setting depend on resource controller and will be either a percentage/fraction (e.g. percentage, fraction) or an absolute amount (number of pages, ticks, bytes/sec) of the total resource available.

    ckrm_##res##_get_usage : get the usage of ##res## resource by a given class.

    The units for the usage depend on the metric used by the resource controller e.g. the cpu controller could return ticks while the io controller could return bytes/sec.

    ckrm_##res##_change_class(tsk,cls) : change the class of task tsk to cls. For memory, change class of tsk->mm to cls

    The core patch introduces pointers to individual resource class objects in the task_struct. These objects are created by the resource controllers and contain controller-specific data. The task struct also contains a pointer to user-specified tag that the classification module could choose to use for classification.

    The core patch defines dummy functions for each of the cpu, mem, io and net classes for testing. It declares a class struct per resource (the cpu resource being shown for concreteness)

    struct ckrm_cpu_class { ulong share, ulong usage }

    and allocates a default instance of it (ckrm_dflt_cpu_classobj). The dummy function definitions allocate and free instances of ckrm_cpu_class, set its share, get its usage or assign a task's cpu class to it. However, there is no enforcement of the share specification of these dummy classes and the usage information is always zero.

    A real cpu controller that enforces per-class shares and records per-class usage would need to comment out the dummy definitions for the cpu resource (leaving the rest alone) and replace it with its own declaration of a ckrm_cpu_class and definitions for the functions above and a default ckrm_cpu_class object.

    The same requirements hold for mem, io and net controllers.

  2. Classification callback API A classification module supporting dynamic reclassification of tasks will require hooks into various kernel functions that are called when a task is created or its major attributes (such as uid, gid or the program it is executing) change. These hooks allow the classification module to execute code that potentially reclassifies the task or its mm.

    The core patch defines a table of callback functions that can be populated by a classification module. The patch also modifies the appropriate kernel functions to ensure that they call the callback functions if they are defined.

    The classification callback API consists of:

    ckrm_register_engine(cbs): populate the callback table using the functions supplied in cbs.
    ckrm_unregister_engine : clear the callback table

    ckrm_cb_fork : on fork/clone/vfork
    ckrm_cb_exit : on sys_exit
    ckrm_cb_exec : on sys_execve
    ckrm_cb_login : on a new user login. Hook not implemented yet.
    ckrm_cb_id : single callback from all functions changing the real or effective uid, gid of a task
    ckrm_cb_useradd : on user addition
    ckrm_cb_userdel : on user deletion

    A classification module needs to define its own table of callback functions and register it. It can choose to implement only a subset of the callbacks - the undefined ones are never called.


29 Aug 2003

SourceForge.net Logo