Re: dm: lower bio-based reservation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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


[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux