Kernel Manager

The Kernel Manager is responsible for matching incoming Task requests with available kernel resources, and starting the selected kernel. It also passes data and error status between the calling application and the selected kernel.

The Kernel Manager maintains a pool of kernels reserved for its exclusive use, the size of which is controlled by an environment variable. The pool is initially empty. Kernel licensing is described in detail in Kernel Licensing.

At any time, a particular kernel in the pool can be in one of two states:

Active - The kernel is executing a Task request in component mode.
Dormant - The kernel is idle, awaiting activation by the Kernel Manager.

When a Task request comes into the Kernel Manager, it compares various security requirements of the request with the same attributes of each dormant kernel. As soon as a match is found, the Kernel Manager dispatches the request (and parameters) to that kernel. If a match is not found, the Kernel Manager starts one with the required attributes and passes it the Task request to execute. If the kernel pool limit had been reached, the Kernel Manager first chooses a dormant kernel to shut down. If the kernel pool is full and all pool kernels are active, the Kernel Manager returns an error status to the Task requestor.

Next, the activated kernel executes the Task. Upon completion of a Task, the kernel passes the outbound parameters and completion status back to the caller via the Kernel Manager. The kernel then reverts to the dormant state, informing the Kernel Manager as it does so. The kernel releases the PROIV licence seat when the kernel is dormant.

There are several advantages to having a Kernel Manager rather than having each kernel wait for a new request from a P4API caller:

Centralised management of kernel and P4API connections. P4API machines do not have to poll for status information about each kernel, reducing start-up latency and network traffic. It also makes detecting network or application failures more reliable, allowing the other end of the connection (either PROIV Client or PROIV Virtual Machine) to be notified.
Improved machine resource utilisation. In many cases, it may be possible to run with a smaller number of kernels than the total number of Task requesters, if all the possible callers do not make their request simultaneously. The number of kernels required in the pool will depend on the ratio of Task execution duration to elapsed time between caller requests.
Enhanced response time. If there is a suitable dormant kernel already in the pool, the Kernel Manager can connect the Task request to that kernel without having to go thorough the (relatively) time- and resource-intensive steps of creating and initialising a new kernel.
Easier to manage system resources needed for Task execution. The pool enables a user-defined number of kernels to be devoted to satisfying Task requests, while leaving others available for non-task (e.g. PROIV Windows Client) use.

Comment on this topic

Topic ID: 540079