On Mon, Aug 30 2010 at 4:33am -0400, Tejun Heo <tj@xxxxxxxxxx> wrote: > On 08/30/2010 06:45 AM, Jun'ichi Nomura wrote: > > Hi Mike, > > > > (08/27/10 23:13), Mike Snitzer wrote: > >>> If there will be no need for supporting a request-based target > >>> with num_flush_requests > 1, the special handling of flush > >>> can be removed. > >>> > >>> And since there is no such target in the current tree, > >>> I don't object if you remove that part of code for good reason. > >> > >> OK, certainly something to keep in mind. But _really_ knowing the > >> multipath FLUSH+FUA performance difference (extra special-case code vs > >> none) requires a full FLUSH conversion of request-based DM anyway. > >> > >> In general, request-based DM's barrier/flush code does carry a certain > >> maintenance overhead. It is quite a bit of distracting code in the core > >> DM which isn't buying us anything.. so we _could_ just remove it and > >> never look back (until we have some specific need for num_flush_requests > >>> 1 in rq-based DM). > > > > So, I'm not objecting to your idea. > > Could you please create a patch to remove that? > > I did that yesterday. Will post the patch soon. 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. 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". Thanks, Mike -- 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
