Hello, On 08/30/2010 02:43 PM, Mike Snitzer wrote: > I did it yesterday also, mine builds on your previous DM patchset... > > I'll review your recent patchset, from today, to compare and will share > my findings. Thanks. :-) > I was hoping we could get the current request-based code working with > your new FLUSH+FUA work without removing support for num_flush_requests > (yet). And then layer in the removal to give us the before and after so > we would know the overhead associated with keeping/dropping > num_flush_requests. But like I said earlier "we _could_ just remove it > and never look back". I tried but it's not very easy because the original implementation depended on the block layer suppressing other requests while flush sequence is in progress. The painful part was that block layer no longer sorts requeued flush requests in front of other front inserted requests, so explicit queue suppressing can't be implemented simply. Another route would be adding a separate wait/wakeup logic for flushes (someone posted a demo patch for that which was almost there but not fully), but it seemed like a aimless effort to build a new facility to rip it out in the next patch. After all, the whole thing seemed somewhat pointless given that writes can't be routed to multiple targets (if writes can't target multiple devices, flushes won't need to either). Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
