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

[Mikulas Patocka <mpatocka@redhat.com>]

> > > Yes, but it's gains very little ... architectures that don't want it can
> > > already turn it off, and it's useful for those, like parisc, who do.
> > 
> > It increases maintainability of the code, reduces bloat and bugs.
> 
> That's not really a good reason.  You can eliminate code because it's
> unused and unikely to be used or you redo it to better or fix it to be
> less buggy.  You don't simply eliminate useful functionality that
> currently has in-tree users, however marginal you might opine those
> users to be.
> 
> James

So show a specific device where the virtual merge accounting is useful.

(1) The device that is often used in alpha or pa-risc environments --- 
because the accounting is not used on other archs.

(2) The device that is performance-sensitive --- not something outdated or 
unusual.

(3) And the device that has limited sg-list size, so that generic I/O 
requests made by the kernel hit this limit. (if the sg-list is so big that 
nr_phys_segments of most requests fits into it, you don't need to count 
nr_hw_segments --- because nr_hw_segments < nr_phys_segments and 
nr_phys_segments already fits).

[ the device that traverses its sg-list slowly doesn't fall into category 
(3), beacuse virtual merging would happen with or without nr_hw_segments 
accounting ]

Mikulas