>>> On sparc64 it is broken anyway with or without your patch.
The problem is with vmerge accounting in block layer (that is what I'm
proposing to remove), not with vmerge itself.
Vmerge accounting has advantages only if you have device with small amount
of sg slots --- it allows the block layer to create request that has
higher number of segments then the device.
If you have device with for example 1024 slots, the virtual merge
accounting has no effect, because the any request will fit into that size.
Even without virtual merge accounting, the virtual merging will happen, so
there will be no performance penalty for the controller --- the controller
will be programmed with exactly the same number of segments as if virtual
merge accounting was present. (there could be even slight positive
performance effect if you remove accounting, because you burn less CPU
cycles per request)
If you have device will small number of sg slots (16 or so), vmerge
accounting can improve performance by creating requests with more than 16
segments --- the question is: is there any such device? And is the device
performance-sensitive? (i.e. isn't it such an old hardware where no one
cares about performance anyway?)
I suppose that no one would manufacture new SCSI card with 16 or 32 sg
slots these days, so the accounting of hardware segments has no effect on
modern hardware.
Mikulas
--
