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