Christoph Hellwig, on 07/30/2010 05:12 PM wrote:
On Fri, Jul 30, 2010 at 05:09:52PM +0400, Vladislav Bolkhovitin wrote:
Sorry, I can't follow you here. What was the load pattern difference
between the tests in the way how the backend device saw it? I thought,
it was only in absence of the cache flush commands (SYNCHRONIZE_CACHE?)
in the write through case, but looks like there is something more different?
The only difference in commands is that we see no SYNCHRONIZE_CACHE.
The big picture difference is that we also only drain the queue just
to undrain it ASAP, instead of keeping it drained over a sequence
of SYNCHRONIZE_CACHE + WRITE + SYNCHRONIZE_CACHE, which can make
a huge difference for a device with very low latencies like the SSD
in my laptop.
It's weird. I can only explain it if:
1. The device fully or particularly lies about write through mode. Under
"particularly" I mean something like if the response returned when the
writes "almost" sent to the media.
2. The device has very ineffective SYNCHRONIZE_CACHE implementation. For
instance, it has relatively slow internal cache scan (you do complete
cache flush, not only affected by the previous writes blocks, correct?).
It would be good if you performed your test on some software SCSI target
device, where we can fully control and see what's going on inside.
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
