08-18-2009, 06:56 PM
06-06-2011, 06:23 PM
General Description
In this paper the author introduced several mechanisms to deal with the problem of LiveLock. The main idea is to prevent the OS from being occupied by I/O scheduling. The result is to implement a sub system such that “fairly allocate resources among packet reception, packet transmission, protocol processing, other I/O processing, system housekeeping, and application processing”. Though it’s meant to deploy the mechanisms in general-purpose I/O handling, according to the test applications the target supposed to be the networking in a network server.
Analysis and Possible Improvement
Before modification the kernel applied fully priority interrupt based scheduling. Packet input had the highest priority, thus when input flooding the processor will be occupied with the input reception.
The author combined interrupt with polling mechanism so that the receipt, processing, and output formed a sequential procedure. Several procedures formed one cycle of polling. The workload inside the interrupt handler is reduced. The work is grouped in cycle of polling and moved to new kernel threads. New kernel threads mean differentiating the whole work by two parts: interrupt signaling part which would return sooner and sequential work part. This mechanism works well to solve the problems of input dominating, fair resource allocation, and output queuing. There would be some overhead for implementing a subsystem inside the kernel. But it provided a solution when facing livelock which would be trigged by input threshold. Though I’ve no idea about which mechanism the kernel will choose when there’s no need to change interrupt, this modification seems to be a specific solution for network card.
Since interrupt and interrupt handler can’t be interrupted or preempted inside kernel thread, the atomicity is guaranteed. When we think about the livelock problem in multicore system, things becomes more interesting and more work need to be done. One thing for sure is that it will depend on the underlining OS while OS for multicore system is not stable yet.
The cycle-count mechanism was used to limit the usage of kernel by packet tasks. The measurement of kernel usage is detected by the count of instruction cycle provided by the hardware. It’s possible to use a simple timeout for the same purpose since the kernel can’t preempt its kernel thread. Cycle-count mechanism is passive while timeout is active. Because kernel thread will voluntarily release the kernel by using timeout. The benefit of cycle-count mechanism is that hardware based measurement is more accurate and the kernel capability is used more efficiently under high pressure.
In this paper the author introduced several mechanisms to deal with the problem of LiveLock. The main idea is to prevent the OS from being occupied by I/O scheduling. The result is to implement a sub system such that “fairly allocate resources among packet reception, packet transmission, protocol processing, other I/O processing, system housekeeping, and application processing”. Though it’s meant to deploy the mechanisms in general-purpose I/O handling, according to the test applications the target supposed to be the networking in a network server.
Analysis and Possible Improvement
Before modification the kernel applied fully priority interrupt based scheduling. Packet input had the highest priority, thus when input flooding the processor will be occupied with the input reception.
The author combined interrupt with polling mechanism so that the receipt, processing, and output formed a sequential procedure. Several procedures formed one cycle of polling. The workload inside the interrupt handler is reduced. The work is grouped in cycle of polling and moved to new kernel threads. New kernel threads mean differentiating the whole work by two parts: interrupt signaling part which would return sooner and sequential work part. This mechanism works well to solve the problems of input dominating, fair resource allocation, and output queuing. There would be some overhead for implementing a subsystem inside the kernel. But it provided a solution when facing livelock which would be trigged by input threshold. Though I’ve no idea about which mechanism the kernel will choose when there’s no need to change interrupt, this modification seems to be a specific solution for network card.
Since interrupt and interrupt handler can’t be interrupted or preempted inside kernel thread, the atomicity is guaranteed. When we think about the livelock problem in multicore system, things becomes more interesting and more work need to be done. One thing for sure is that it will depend on the underlining OS while OS for multicore system is not stable yet.
The cycle-count mechanism was used to limit the usage of kernel by packet tasks. The measurement of kernel usage is detected by the count of instruction cycle provided by the hardware. It’s possible to use a simple timeout for the same purpose since the kernel can’t preempt its kernel thread. Cycle-count mechanism is passive while timeout is active. Because kernel thread will voluntarily release the kernel by using timeout. The benefit of cycle-count mechanism is that hardware based measurement is more accurate and the kernel capability is used more efficiently under high pressure.