On 2020-04-13 6:57 p.m., Martin K. Petersen wrote:
Doug,
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.
Minor nit: I agree with the code and the use case. But the commit
description should reflect what the code actually does (not much in the
absence of cache, etc.)
On reflection, there is no reason why the implementation of PRE-FETCH
for a scsi_debug ramdisk can't do what it implies. IOWs get those blocks
into (say) the machine's L3 cache. This is to speed a following
VERIFY(BYTCHK=1) [or NVMe Compare ***] that will use those blocks. The
question is, how?
I have added this to resp_pre_fetch():
memcpm(ramdisk_ptr, ramdisk_ptr, num_blks*blk_sz);
Will that be optimized out? If so, is there a better/faster way to
encourage a machine to populate its cache?
Doug Gilbert
*** I have a recent WD SN550 SSD whose sequential read speed (after
data (zeros) written) is around 1200 MB/sec. Its read speed _before_
data was written was around 25 KB/sec !! And its compare speed
(with random data written) is a very disappointing 25 MB/sec.
