Re: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq_segments about VMERGE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On sparc64 it is broken anyway with or without your patch.

Yeah, we need to modify SPARC64 IOMMU code (I'm not sure that it's
worth). Right now, the best fix is setting BIO_VMERGE_BOUNDARY to 0.


And alpha alone doesn't justify substantial code bloat in generic block
layer. So I propose this patch to drop it at all.

Jens, what do you think about removing VMERGE code?

Actually, it's code I did.

There are plusses and minusses to all of this.  The original vmerge code
was done for sparc ... mainly because the benefits of virtual merging
can offset the cost of having to use the iommu.  However, most
architectures didn't use it.  When I fixed it up to work for parisc (and
introduced the parameters) we were trying to demonstrate that using it
was feasible.

The idea behind vmerging is that assembling and programming sg lists is
expensive, so you want to do it once.  Either in the iommu or in the
driver sg list, but not in both.  There is evidence that it saves around
7% or so on drivers.  However, for architectures that can do it, better
savings are made simply by lifting the iommu out of the I/O path (so
called bypass mode).

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 suspect with IOMMUs coming back (and being unable to be bypassed) with
virtualisation, virtual merging might once more become a significant
value.

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

James


--
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux