> > Request-based memory consumption cannot be easily reduced, it uses > > GFP_ATOMIC to allocate all entries at once, and if it fails, request is > > pushed back to the block layer. Thus it needs reservations to process at > > least one complete request. > > But couldn't the rq-based reserves be shared and simply protected by a > lock? I you don't need a special lock --- mempools are protected by a lock on their own. > We'd need a scheme where we provided a pool+lock per rq-based DM layer > (for the conceptual possibility that we'd stack request-based DM devices > even though in practice it isn't done). > > Being aware of how deep the stacking is isn't very elegant though > (breaks DM abstraction). > > Not to mention, we'd also serialize cloned-request allocations (note it > wouldn't serialize IO, just the allocations). > > Chances are it would hurt performance for heavy IO to many mpath > devices.. so I'm not saying it is a wonderful solution. But can you > guys think of variants of this shared pool scheme that might work? If you don't stack rm-based devices, then a shared mempool may work. It is prone to livelocks --- suppose continuous stream of IO to one device blocking progress on another device. But if we suppose that that continuous stream won't be infinite or that some memory is freed eventually, it may work. Mikulas > Mike > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
