Offloading RAID functions to a graphics coprocessor

Systems and methods for using a graphics processor to perform RAID parity functions may improve disk access performance. A method is provided for configuring a graphics processor to perform XOR parity computations when data is written to the RAID array. Another method is provided for configuring the graphics processor to perform the XOR parity computations to restore data when a disk is damaged. Using the graphics processor as a coprocessor to offload parity computations from a central processing unit may improve disk access performance and overall system performance.

BACKGROUND OF THE INVENTION

1. Field of the Invention

One or more aspects of the invention generally relate to a parity function in RAID systems, and more particularly to using a graphics processor to compute XOR parity and use parity to reproduce data stored on a degraded disk.

2. Description of the Related Art

Conventional computing systems including a RAID array perform parity computations using a central processing unit (CPU) or a dedicated special purpose processor. Parity must be recomputed whenever data is written to the RAID array and is used to reconstruct data stored on a degraded disk.

FIG. 1Ais a conceptual diagram of a prior art organization of data in a RAID array100. RAID array100includes four disks, disk110,120,130, and140. The disks are organized in stripes, where a stripe includes data elements from each disk. For example, a first stripe includes data10, data20, data30, and parity40. Similarly, a second strip includes parity11, data21, data31, and data41. Parity40is computed as the XOR of data10, data20, and data30and parity11is computed as the XOR of data21, data31, and data41. If any one of disks110,120,130, or140is degraded the data elements stored on that disk may be recovered using the data elements stored on the other disks. For example, data43may be reconstructed by computing the XOR of parity33, data23and data13. Similarly, data12may be reconstructed by computing the XOR of parity22, data32, and data42.

FIG. 1Bis a block diagram of a prior art system150including a CPU155, system memory170, chipset160, and RAID array100. When data is written to RAID array100by CPU155parity must be recomputed for each affected stripe of RAID array100. If needed, the data portions of the affected stripes are transferred by chipset160from RAID array100to system memory170. CPU155reads the data portions and computes parity for each affected stripe and stores the parity value in a parity buffer in system memory170. CPU155typically performs an XOR operation on a cache line at a time, reading two cache lines, XORing the two cache lines, and storing the result in system memory170. The reading, XORing, and writing is repeated for the stripe data from each disk until all of the stripe data is XORed to produce the parity data for the stripe. When CPU155is computing parity it is unavailable to perform other processing. When CPU155is finished computing parity, the parity buffer stored in system memory170is written to RAID array100by chipset160.

Similarly, when a disk is degraded, the data elements from the other disks are transferred by chipset160from RAID array100to system memory170. CPU155reads the data elements and reconstructs the data for the degraded disk and stores the data in a data buffer in system memory170. When CPU155is reconstructing the data it is unavailable to perform other processing. When CPU155is finished reconstructing the data, the data buffer stored in system memory170is written to the degraded disk by chipset160.

Accordingly, it is desirable offload the parity functions, e.g., computing parity and reconstructing data using parity, to another processor to free CPU155to perform other operations. Offloading the parity functions from CPU155may improve overall system performance.

SUMMARY OF THE INVENTION

The current invention involves new systems and methods for using a graphics processor to perform RAID parity functions. A method is provided for configuring a graphics processor to perform XOR parity computations when data is written to the RAID array. Another method is provided for configuring the graphics processor to perform the XOR parity computations to restore data when a disk is damaged. Using the graphics processor as a coprocessor to offload parity computations from a central processing unit may improve disk access performance and overall system performance.

Various embodiments of the invention include a system for using a graphics processor as a coprocessor to perform RAID parity functions. The system includes a RAID array, a media communications processor, a central processing unit, and a graphics processor. The RAID array includes at least three disk drives configured to store data. The media communications processor coupled to the RAID array and configured to read the data from the RAID array and write the data to the RAID array. The central processing unit coupled to the media communications processor and configured to access the data stored on the RAID array. The graphics processor coupled to the media communications processor and configured to perform the RAID parity functions.

Various embodiments of a method of the invention for using a graphics processor as a coprocessor to perform RAID parity functions include notifying the graphics processor that a source buffer and a data buffer are available for processing, performing a bitwise XOR of the source buffer and the data buffer to produce a parity value, storing the parity value in a parity buffer, and notifying a storage driver that the parity buffer is available for storage in a RAID array.

Various embodiments of the invention are a computer-readable medium containing a program which, when executed by a computing device, configures a graphics processor to perform a process for computing RAID parity functions. The process includes notifying the graphics processor that a source buffer and a data buffer are available for processing, performing a bitwise XOR of the source buffer and the data buffer to produce a parity value, storing the parity value in a parity buffer, and notifying a storage driver that the parity buffer is available for storage in a RAID array.

DETAILED DESCRIPTION

The present invention provides a means for using an auxiliary processor, such as a graphics processor to perform RAID parity functions. Overall system performance may be improved by offloading RAID parity functions from the CPU to a graphics processor. The graphics processor may be configured to compute parity and to reconstruct data for a degraded disk. The graphics processor may use a dedicated frame buffer memory to store intermediate results and the computed parity buffer and/or data buffer.

FIG. 2Ais a block diagram of an exemplary embodiment of a respective system200in accordance with one or more aspects of the present invention. System200includes a CPU220, a system memory210, a MCP (media and communications processor)230, a graphics subsystem260, and a RAID array250. System200may be a desktop computer, server, laptop computer, palm-sized computer, tablet computer, game console, portable wireless terminal such as a personal digital assistant (PDA) or cellular telephone, computer based simulator, or the like. CPU220may include a system memory controller to interface directly to system memory210. In alternate embodiments of the present invention, CPU220may communicate with system memory210through a system interface, e.g., I/O (input/output) interface or a bridge device.

MCP230is coupled to CPU220via a high bandwidth interface, front side bus225. In some embodiments of the present invention front side bus225uses a peripheral component interface (PCI) hypertransport protocol. MCP230includes a storage controller240, such as a RAID5controller, a RAID0controller, a RAID1controller, or the like. In other embodiments of the present invention, MCP230may include additional ports such as universal serial bus (USB), accelerated graphics port (AGP), and the like. Each hard disk251,252,253, and254may be replaced or removed, so at any particular time, system200may include fewer or more hard disk drives. Storage controller240facilitates data transfers between CPU220, Graphics subsystem260, and RAID array250, including transfers for performing parity functions. In some embodiments of the present invention, storage controller240performs block striping and/or data mirroring based on instructions received from storage driver112. Each disk150coupled to storage controller240includes drive electronics that control storing and reading of data within the individual disk251,252,253, and254. Data is passed between storage controller240and each disk251,252,253, and254via a bidirectional bus. Each hard disk drive150and155includes drive electronics that control storing and reading of data within the individual hard disk drive.

System memory210stores programs and data used by CPU220, including storage driver212and a graphics driver214. Storage driver212communicates between the operating system (OS) and storage controller240within MCP230to perform RAID management functions such as detection and reporting of disk failures, maintaining state data for each disk within RAID array250, and transferring data between system memory210and RAID array250. Graphics driver214communicates between the OS and graphics processor265within graphics subsystem260, configuring graphics processor265to process data according to graphics programs and to read or write data to/from system memory210. Graphics subsystem260is coupled to MCP230via a high bandwidth bus, such as PCI Express bus248. In some embodiments of the present invention, graphics processor265is an auxiliary processor configured to perform a variety of different types of processing to offload CPU220. For example graphics processor265may perform media processing of video data, audio data, or processing of other types of data to offload CPU220.

FIG. 2Bis a conceptual diagram of the communication paths between hardware and software in the system ofFIG. 2Ain accordance with one or more aspects of the present invention. Graphics driver214translates graphics programs into instructions for execution by graphics processor265. Graphics driver214also configures graphics processor265to perform parity functions, including reading data and parity values from system memory210. Storage driver112communicates between OS280and storage controller240to transfer data between RAID array250and system memory210. Storage driver112and graphics driver214communicate with each other to offload the parity functions as described in conjunction withFIGS. 3A and 4A. Storage driver112and graphics driver214are provided by the system designer and/or manufacturer of system200.

FIG. 3Ais an exemplary embodiment of a method of using graphics subsystem260as a coprocessor to perform RAID parity functions in accordance with one or more aspects of the present invention. In step3000S280requests storage driver212to write data to a disk in RAID array250. In step305storage driver212determines if the write request will replace one or more entire stripes of RAID array250, and, if so, storage driver proceeds to step320. When an entire stripe is replaced it is not necessary to read data from RAID array250. If, in step305storage driver212determines that an entire stripe will not be written, then in step310storage driver212reads the stripe(s) that will be affected by the write request. The stripe(s) read in step310are stored in one or more source buffers in system memory210. In one embodiment of the present invention, data for a single stripe in stored in a different source buffer for each disk. In other embodiments of the present invention each stripe is stored in a single source buffer. In step315storage driver212inserts the write data into the source buffer(s) affected by the write. Each source buffer that includes write data is called a data buffer. When an entire stripe is written all of the source buffers for the stripe are data buffers.

In step320storage driver212determines if graphics subsystem260is busy and not available to perform parity functions. If, in step320storage driver212determines that graphics subsystem260is busy, then in step330CPU220(instructed by storage driver212) computes an XOR parity value for each affected stripe and stores the parity value(s) in a parity buffer in system memory210. In step335CPU220sends a message to storage driver212that the parity computation is complete.

If, in step320storage driver212determines that graphics subsystem260is not busy, then in step325storage driver212sends a message to graphics driver214to retrieve the data buffer(s) from system memory210and graphics processor265reads (via direct memory access) the data and source buffers from system memory210and stores the data and source buffers in local memory268, i.e., frame buffer memory. In step340graphics driver214configures graphics processor265to compute an XOR parity value for each affected stripe, as described in conjunction withFIG. 3B, and store the parity value(s) in a parity buffer in system memory210. In step345graphics driver214sends a message to storage driver212that the parity computation is complete. In step350storage driver212retrieves the parity buffer from system memory210. In step355storage driver212writes the affected stripe(s), including parity, to RAID array250.

FIG. 3Bis an exemplary embodiment of a method of performing step340ofFIG. 3Ain accordance with one or more aspects of the present invention. In step360graphics driver214configures graphics processor265to perform a bitwise XOR on a first buffer and a second buffer, where the first and second buffers may each be either a data or source buffer for a stripe, and store the result in a parity buffer in local memory268. In some embodiments of the present invention, graphics processor265may not store the data, source, and parity buffers in local memory268and instead may read and write the buffers to/from system memory210.

Graphics driver214may configure graphics processor265to perform a bitwise XOR using a shader program to read the first and second buffers as texture data and produce the parity values. Alternatively, graphics driver214may instruct graphics processor265to perform a source destination bitmask (SDB) operation to combine the first and second buffers using an XOR to produce the parity values.

In step365graphics driver214(or graphics processor265) determines if another source or data buffer should be included in the parity computation for the stripe, and, if so, in step370graphics processor265performs a bitwise XOR between the additional buffer and the parity buffer and stores the result in the parity buffer. Steps365and370are repeated for each source and data buffer for a stripe. If, in step365graphics driver214(or graphics processor265) determines that all of the source and data buffers have been included in the parity computation for the stripe, then the parity computation is complete and graphics driver214proceeds to step345.

FIG. 4Ais another exemplary embodiment of method of using graphics subsystem260as a coprocessor to perform RAID parity functions in accordance with one or more aspects of the present invention. In step4000S280requests storage driver212to read data from a degraded disk in RAID array250. In step405storage driver212reads the stripe(s) requested by OS280. The stripe(s) read in step405are stored in one or more source and parity buffers in system memory210.

In step410storage driver212determines if graphics subsystem260is busy and not available to perform parity functions. If, in step410storage driver212determines that graphics subsystem260is busy, then in step415CPU220(instructed by storage driver212) reconstructs the data for the degraded disk and stores the reconstructed data for the degraded disk in a data buffer in system memory210. In step420CPU220sends a message to storage driver212that the data restoration is complete.

If, in step410storage driver212determines that graphics subsystem260is not busy, then in step425storage driver212sends a message to graphics driver214to retrieve the source and parity buffers from system memory210and graphics processor265reads (via direct memory access) the source and parity buffers from system memory210and stores the source and parity buffers in local memory268. In step430graphics driver214configures graphics processor265to reconstruct the data for the degraded disk, as described in conjunction withFIG. 4B, and store the reconstructed data in a data buffer in system memory210. In step435graphics driver214sends a message to storage driver212that the data restoration is complete. In step440storage driver212retrieves the data buffer from system memory210. In step445storage driver212returns the data requested by OS280in step400and notifies OS280that the read is complete.

FIG. 4Bis an exemplary embodiment of a method of performing step430ofFIG. 4Ain accordance with one or more aspects of the present invention. In step460graphics driver214configures graphics processor265to perform a bitwise XOR on a first buffer and a second buffer, where the first buffer is a parity buffer for a stripe and the second buffer is a source buffer for the same stripe, and store the result in a data buffer in local memory268. In some embodiments of the present invention, graphics processor265may not store the data, source, and parity buffers in local memory268and instead may read and write the buffers to/from system memory210.

As previously described in conjunction withFIG. 3B, graphics driver214may configure graphics processor265to perform a bitwise XOR using a shader program to read the first and second buffers as texture data and produce the reconstructed data. Alternatively, graphics driver214may instruct graphics processor265to perform a source destination bitmask (SDB) operation to combine the first and second buffers using an XOR to produce the reconstructed data.

In step465graphics driver214(or graphics processor265) determines if another source should be processed to reconstruct the data for the stripe, and, if so, in step470graphics processor265performs a bitwise XOR between the additional buffer and the data buffer and stores the result in the data buffer. Steps465and370are repeated for each source buffer (except the degraded source buffer) in a stripe. If, in step465graphics driver214(or graphics processor265) determines that all of the source buffers have been included in the data reconstruction for the stripe, then the parity computation is complete and graphics driver214proceeds to step435.

By configuring graphics processor265to perform the RAID parity functions, a resource which is otherwise idle is used to offload CPU220, permitting CPU220to perform other operations. Overall system performance may be improved by offloading the parity functions and using graphics processor265as a coprocessor. Persons skilled in the art will appreciate that any system configured to perform the method steps ofFIGS. 3A,3B,4A, or4B or their equivalents, is within the scope of the present invention.

FIG. 5is a block diagram of an exemplary embodiment of graphics subsystem260in accordance with one or more aspects of the present invention. Graphics subsystem260includes a local memory268and programmable graphics processor265. CPU220communicates with graphics subsystem260via a connection, such as PCI express bus248and a graphics interface517within programmable graphics processor265. Data, program instructions, and commands received at graphics interface517can be passed to a graphics processing pipeline503or written to a local memory268through memory management unit520. Programmable graphics processor265uses memory to store surface data, including texture maps, source buffers, data buffers, and parity buffers, and program instructions, where surface data is any data that is input to or output from computation units within programmable graphics processor205.

In addition to graphics interface517, programmable graphics processor265includes a graphics processing pipeline503, memory management unit520and an output controller580. Data and program instructions received at graphics interface517can be passed to a geometry processor530within graphics processing pipeline503or written to local memory268through memory management unit520. In addition to communicating with local memory268, and graphics interface517, memory management unit520also communicates with graphics processing pipeline503and output controller580through read and write interfaces in graphics processing pipeline503and a read interface in output controller580.

Within graphics processing pipeline503, geometry processor530and a programmable graphics fragment processing pipeline, fragment processing pipeline560, perform a variety of computational functions. Some of these functions are table lookup, scalar and vector addition, multiplication, division, coordinate-system mapping, calculation of vector normals, tessellation, calculation of derivatives, interpolation, filtering, and the like. Fragment processing pipeline560may also be configured to perform Boolean operations including XOR. Geometry processor530and fragment processing pipeline560are optionally configured such that data processing operations are performed in multiple passes through graphics processing pipeline503or in multiple passes through fragment processing pipeline560. Each pass through programmable graphics processor265, graphics processing pipeline503or fragment processing pipeline560concludes with optional processing by a raster operations unit565.

Vertex programs are sequences of vertex program instructions compiled for execution within geometry processor530and rasterizer550. Shader programs are sequences of shader program instructions compiled for execution within fragment processing pipeline560. Geometry processor530receives a stream of program instructions (vertex program instructions and shader program instructions) and data from graphics interface517or memory management unit520, and performs vector floating-point operations or other processing operations using the data. The program instructions configure subunits within geometry processor530, rasterizer550and fragment processing pipeline560. The program instructions and data are stored in graphics memory, e.g., portions of system memory210, local memory268, or storage resources within programmable graphics processor505.

When a portion of system memory210is used to store program instructions and data, the portion of system memory210can be uncached so as to increase performance of access by programmable graphics processor265. Alternatively, configuration information is written to registers within geometry processor530, rasterizer550and fragment processing pipeline560using program instructions, encoded with the data, or the like.

It may be advantageous to store computed intermediate data, such as computed parity values or data values in local memory268. For example, intermediate results, e.g., partially computed parity values or reconstructed data values, may be stored in buffer542, e.g., a parity buffer or data buffer, in local memory268. Due to the nature of graphics data processing, the interface between memory management unit520and local memory268is typically a high bandwidth interface to facilitate transfers of data between graphics processing pipeline503and local memory268. For example values may be read by fragment processing pipeline560from source, data, or parity buffers stored in local memory268, parity and data values (final or intermediate) are computed, and the results are transferred into local memory268for storage. During the reconstruction of a data buffer or computation of a parity buffer memory the data transfers may occur within graphics subsystem260, freeing front side bus225for other data transfers. Using graphics subsystem260to perform RAID parity computations offloads CPU220and front side bus225, permitting CPU220to perform other operations and possibly improving overall system performance.

Data processed by geometry processor530and program instructions are passed from geometry processor530to a rasterizer550. Rasterizer550is a sampling unit that processes primitives and generates sub-primitive data, such as fragment data, including parameters associated with fragments (texture identifiers, texture coordinates, and the like). Rasterizer550converts the primitives into sub-primitive data by performing scan conversion on the data processed by geometry processor530. Rasterizer550outputs fragment data and shader program instructions to fragment processing pipeline560. When geometry processor530and rasterizer550are configured to perform RAID parity functions, data from source, data, or parity buffers may be simply passed through those units.

The shader programs configure the fragment processing pipeline560to process fragment data by specifying computations and computation precision. Fragment shader555is optionally configured by shader program instructions such that fragment data processing operations are performed in multiple passes within fragment shader555. Fragment shader555outputs the shaded fragment data, e.g., parity values or reconstructed data values, and codewords generated from shader program instructions to raster operations unit565.

Raster operations unit565includes a read interface and a write interface to memory management unit520through which raster operations unit565accesses data stored in local memory268or system memory210. Raster operations unit565optionally performs near and far plane clipping and raster operations, such as stencil, z test, blending, and the like, using the fragment data and pixel data stored in local memory268or system memory210at a pixel position (buffer address specified by x,y coordinates) associated with the processed fragment data, e.g., computed parity values or reconstructed data values. The output data from raster operations unit565is written back to local memory268or system memory210at the buffer address associated with the output data and the results.

When processing is completed, an output585of graphics subsystem260is provided using output controller580. Alternatively, CPU220reads the buffer, such as buffer542, stored in local memory268through memory management unit520, graphics interface517and MCP230. Output controller580is optionally configured by opcodes to deliver data to a display device, network, electronic control system, other system200, other graphics subsystem260, MCP230, or the like.

FIG. 6is a block diagram of another exemplary embodiment of a respective system, system600, in accordance with one or more aspects of the present invention. In contrast to system500, the graphics processing functionality is integrated into CPU620by the inclusion of a graphics core660. In this embodiment of the present invention, the parity functions may be offloaded from CPU620to graphics core660by storage driver612. Intermediate results of the parity functions computed by graphics core660, e.g., parity values and reconstructed data values, are stored in system memory610. MCP630, storage controller640, RAID array650, and disks651,652,653, and654correspond to MCP230, storage controller240, RAID array250, and disks251,252,253, and254, respectively.

While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow. The foregoing description and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The listing of steps in method claims do not imply performing the steps in any particular order, unless explicitly stated in the claim.

All trademarks are the respective property of their owners.