Home
last modified time | relevance | path

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

/openbmc/linux/drivers/scsi/
H A Dscsi_debug.ced9f3e25 Tue Apr 21 10:14:22 CDT 2020 Douglas Gilbert <dgilbert@interlog.com> scsi: scsi_debug: Implement PRE-FETCH commands

Many disks implement the SCSI PRE-FETCH commands. One use case might be a
disk-to-disk compare, say between disks A and B. Then this sequence of
commands might be used: PRE-FETCH(from B, IMMED), READ(from A), VERIFY
(BYTCHK=1 on B with data returned from READ). The PRE-FETCH (which returns
quickly due to the IMMED) fetches the data from the media into B's cache
which should speed the trailing VERIFY command. The next chunk of the
compare might be done in parallel, with A and B reversed.

The implementation tries to bring the specified range in main memory into
the cache(s) associated with this machine's CPU(s) using the
prefetch_range() function.

Link: https://lore.kernel.org/r/20200421151424.32668-7-dgilbert@interlog.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
ed9f3e25 Tue Apr 21 10:14:22 CDT 2020 Douglas Gilbert <dgilbert@interlog.com> scsi: scsi_debug: Implement PRE-FETCH commands

Many disks implement the SCSI PRE-FETCH commands. One use case might be a
disk-to-disk compare, say between disks A and B. Then this sequence of
commands might be used: PRE-FETCH(from B, IMMED), READ(from A), VERIFY
(BYTCHK=1 on B with data returned from READ). The PRE-FETCH (which returns
quickly due to the IMMED) fetches the data from the media into B's cache
which should speed the trailing VERIFY command. The next chunk of the
compare might be done in parallel, with A and B reversed.

The implementation tries to bring the specified range in main memory into
the cache(s) associated with this machine's CPU(s) using the
prefetch_range() function.

Link: https://lore.kernel.org/r/20200421151424.32668-7-dgilbert@interlog.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>