Home
last modified time | relevance | path

Searched hist:b90f90d2 (Results 1 – 1 of 1) sorted by relevance

/openbmc/linux/drivers/scsi/aacraid/
H A Daachba.cb90f90d2 Fri Jul 27 08:48:49 CDT 2007 Salyzyn, Mark <mark_salyzyn@adaptec.com> [SCSI] aacraid: add SCSI SYNCHONIZE_CACHE range checking

Customer running an application that issues SYNCHRONIZE_CACHE calls
directly noticed the broad stroke of the current implementation in the
aacraid driver resulting in multiple applications feeding I/O to the
storage causing the issuing application to stall for long periods of
time. By only waiting for the current WRITE commands, rather than all
commands, to complete; and those that are in range of the
SYNCHRONIZE_CACHE call that would associate more tightly with the
issuing application before telling the Firmware to flush it's dirty
cache, we managed to reduce the stalling. The Firmware itself still
flushes all the dirty cache associated with the array ignoring the
range, it just does so in a more timely manner.

Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
b90f90d2 Fri Jul 27 08:48:49 CDT 2007 Salyzyn, Mark <mark_salyzyn@adaptec.com> [SCSI] aacraid: add SCSI SYNCHONIZE_CACHE range checking

Customer running an application that issues SYNCHRONIZE_CACHE calls
directly noticed the broad stroke of the current implementation in the
aacraid driver resulting in multiple applications feeding I/O to the
storage causing the issuing application to stall for long periods of
time. By only waiting for the current WRITE commands, rather than all
commands, to complete; and those that are in range of the
SYNCHRONIZE_CACHE call that would associate more tightly with the
issuing application before telling the Firmware to flush it's dirty
cache, we managed to reduce the stalling. The Firmware itself still
flushes all the dirty cache associated with the array ignoring the
range, it just does so in a more timely manner.

Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>