On Sun, Aug 05, 2007 at 02:35:04PM -0700, Daniel Phillips (phillips@xxxxxxxxx) wrote: > On Sunday 05 August 2007 08:01, Evgeniy Polyakov wrote: > > On Sun, Aug 05, 2007 at 01:06:58AM -0700, Daniel Phillips wrote: > > > > DST original code worked as device mapper plugin too, but its two > > > > additional allocations (io and clone) per block request ended up > > > > for me as a show stopper. > > > > > > Ah, sorry, I misread. A show stopper in terms of efficiency, or in > > > terms of deadlock? > > > > At least as in terms of efficiency. Device mapper lives in happy > > world where memory does not end and allocations are fast. > > Are you saying that things are different for a network block device > because it needs to do GFP_ATOMIC allocations? If so then that is just > a misunderstanding. The global page reserve Peter and I use is > available in interrupt context just like GFP_ATOMIC. No, neither device needs atomic allocations, I just said that device mapper is too expensive, since it performs alot of additional allocations in the fast path and is not designed to cases when allocation fails, since there is no recovery path and (maybe because of this) mempool allocation waits forever until there is free memory and can not fail. -- Evgeniy Polyakov - 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
