On Tue, Jun 21, 2011 at 04:08:52PM -0400, Mikulas Patocka wrote: > This patch may also improve CPU consumption a little bit by not providing > a merge function on linear devices, where it is not needed. That would be a trade-off - dependent on the actual table construction. The risk from not calling the merge function is that you'll necessitate splitting (and consequent possible reordering). Historically we found it highly desirable to avoid splitting vs. an unnoticeable overhead from calling the merge function. Probably needs some numbers with different sorts of tables and workloads to see where the trade-off might now lie. Essentially my position is that the linear merge function: Improves *some* configurations and processing of specific bios noticeably; Has neglible overhead in the cases it doesn't improve. So to counter that I'd like to see evidence of counter-examples, e.g. It has noticeable overhead in some configurations that don't benefit from it. Then we can debate whether we can distinguish between these classes automatically or make the change globally. (BTW md linear should be included in these tests, as the same considerations ought to apply - if there are solid grounds to make a change, those grounds may apply to both md and dm.) Alasdair -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
