Browse Prior Art Database

Method for binding I/O completion to the originating processor for individual I/O requests.

IP.com Disclosure Number: IPCOM000015724D
Original Publication Date: 2002-Jun-24
Included in the Prior Art Database: 2003-Jun-21
Document File: 1 page(s) / 38K

Publishing Venue

IBM

Abstract

Method for binding I/O completion to the originating processor for individual I/O requests. Disclosed is a method for binding the iodone interrupt of a UNIX* Operating System to the CPU which initiated the original request. When an I/O request is channeled from an application to a device it usually moves through one or more software layers with each layer potentially implementing a queuing mechanism before it gets to the device. There is a great chance that the data structures involved in the I/O operation migrate from one CPU to another as the I/O operation makes progress through different software layers. On completion of the operation, the interrupt is very likely taken on a CPU that did not initiate the I/O operation. In general the I/O operation going down from the application to the device is executed on one or more CPUs and the I/O operation on completion will execute on a different CPU. Thus the completion of an IO request causes the use application data structures to migrate from the one CPU to another at I/O completion time. The proposed solution requires changes to the way an I/O request is originated and how it is completed. The proposed would require changes to the I/O "buf" structure on UNIX* based Operating Systems to allow for a field which indicates the initiating CPU. The devstrat kernel service would store the initiating CPU information in all of the "buf" structures that have been chained together and are being sent to an underlying device driver. The underlying device would ignore this field. When the underlying device driver calls the iodone kernel service to signal the completion of a request, the iodone kernel service would check the initiating CPU field and route the iodone interrupt to the iodone interrupt queue for that CPU. The initiator of the IO request would be interrupted with the iodone when the CPU processes its iodone interrupt queue.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 65% of the total text.

Page 1 of 1

Method for binding I/O completion to the originating processor for individual I/O

requests.

Disclosed is a method for binding the iodone interrupt of a UNIX* Operating System to the CPU which initiated the original request. When an I/O request is channeled from an application to a device it usually moves through one or more software layers with each layer potentially implementing a queuing mechanism before it gets to the device. There is a great chance that the data structures involved in the I/O operation migrate from one CPU to another as the I/O operation makes progress through different software layers. On completion of the operation, the interrupt is very likely taken on a CPU that did not initiate the I/O operation. In general the I/O operation going down from the application to the device is executed on one or more CPUs and the I/O operation on completion will execute on a different CPU. Thus the completion of an IO request causes the use application data structures to migrate from the one CPU to another at I/O completion time.

The proposed solution requires changes to the way an I/O request is originated and how it is completed. The proposed would require changes to the I/O "buf" structure on UNIX* based Operating Systems to allow for a field which indicates the initiating CPU. The devstrat kernel service would store the initiating CPU information in all of the "buf" structures that have been chained together and are being sent to an underlying device dri...