Chaining of sg_tables is used for drivers with big sg tables --- and
vmerge counting is used for drivers with small sg tables. So what do they
have in common?
Summary, what I mean:
* in blk-merge.c, you have 85 lines, that is 16% of the size of the file,
devoted to counting of hw_segments
* it is only used on two architectures, one already outdated (alpha), the
other being discontinued (pa-risc). On all the other architectures,
hw_segments == phys_segments
* it is prone to bugs and hard to maintain, because the same value must be
calculated in blk-merge.c and in architectural iommu functions --- if the
value differs, you create too long request, corrupt kernel memory and
crash (happened on sparc64). Anyone changing blk-merge in the future will
risk breaking something on the architectures that use BIO_VMERGE_BOUNDARY
--- and because these architectures are so rare, the bug will go unnoticed
for long time --- like in the case of sparc64.
* you are just talking how this code is important for performance without
showing any single proof that it really is (temporarily disable
hw_segments accounting by defining BIO_VMERGE_BOUNDARY 0 and get the
numbers).
Mikulas
--