Kernel Event Queue for Multipathing Driver Latency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional multipathing drivers for host computing systems face challenges in managing events due to reliance on system logs, which can lead to unpredictable delays and burdensome maintenance of operating system-specific daemons, especially in diverse operating system environments, compromising the accuracy and accessibility of event records.

Innovation Solution

An event queue is implemented within the multipathing driver installed in the operating system kernel, allowing events to be timestamped locally and stored chronologically without the need for external system logs, reducing reliance on system-specific daemons and minimizing latency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If event records are stored in the system log through operating system daemons, then event information can be recorded and accessed, but unpredictable delays occur and maintenance becomes burdensome across different operating systems

Engineering Contradiction:
Improveaccuracy of event timingVSAvoidlatency in event recording
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts the event recording function from the operating system's system log and daemon processes, and relocates it directly into the multipathing driver kernel module. This extraction eliminates the intermediate layers that cause unpredictable delays, allowing events to be recorded at the source with precise timing without relying on external daemons or system logs.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces an event queue as an intermediary data structure within the kernel that buffers events between their occurrence and retrieval. This queue allows events to be captured immediately with accurate timestamps while enabling flexible, on-demand retrieval by applications without requiring synchronous access or blocking operations.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of operation

If operating system-specific daemons are used to manage event logs, then event information can be exchanged between the multipathing driver and system log, but maintenance complexity increases when operating systems are updated or changed

Engineering Contradiction:
Improveaccessibility of event recordsVSAvoidmaintenance of system-specific daemons
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent creates a universal event queue interface within the kernel that works across all operating systems without requiring OS-specific daemons. The event queue uses standard kernel data structures and synchronization mechanisms that are universally available, making the solution portable and eliminating the need for separate daemon implementations for different operating systems.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The multipathing driver directly manages its own event recording and queueing without external assistance from system daemons. The driver captures events, assigns timestamps, and places them in the queue autonomously, making the system self-sufficient and eliminating the maintenance burden of external daemon processes.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS8904063B1Ordered kernel queue for multipathing events
Publication Date: 2014.12.02 EMC IP HLDG CO LLC
  • US8904063B1 patent drawing
  • US8904063B1 patent drawing
  • US8904063B1 patent drawing

AI summary

An improved technique for handling events in a multipathing driver employs an event queue and a queue manager that run in the kernel of a computing system. The queue manager receives events raised by the multipathing driver, as well as events raised by software constructs, such as application programs. Records of events are added to the event queue in the order the queue manager receives them. Event records may be consumed chronologically by external software. Preferably, the event queue is sufficiently large to store all events arising out of most predicted fault scenarios. Also, the queue manager is sophisticated and can perform certain diagnostic and analysis tasks without the aid of external software.