On Thu, 2012-01-05 at 20:38 -0800, Tejun Heo wrote: > Hello, > > On Thu, Jan 5, 2012 at 8:19 PM, Shaohua Li <shaohua.li@xxxxxxxxx> wrote: > >> For detailed discussion of the bug: > >> > >> http://thread.gmane.org/gmane.linux.kernel.next/20064/focus=20159 > >> > > this is overkill. when plug is added, we found huge performance > > regression, that's why we add INSERT_SORT_MERGE. > > With what workload? I suspect most of the improvements is from merging > across different cfqqs, no? The whole recursive thing can't be very > useful if cross-cfqq merging isn't allowed. Maybe there are specific > cases where last_merge hint merging can be specially effective. I > don't know. Regardless, this is an apparent bug and the block tree > will be pushed mainline pretty soon. If necessary, fix it better > later. Doing complex things inside merge window usually isn't a good > idea. it's not related to the recursive merge. I forgot the detail of the workload why we add INSERT_SORT_MERGE, it's added several months ago anyway. Obviously we shouldn't do complex things inside the merge window. I just didn't agree to disable INSERT_SORT_MERGE, which will bring performance regression for sure. Can we just change CFQ like your first path? Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
