On 09/29/2015 05:17 AM, Alberto Garcia wrote: > On Tue 22 Sep 2015 05:00:05 PM CEST, Max Reitz wrote: > >>> The correct way to solve this seems to be that each BB has its own >>> I/O throttling filter. Actually, if we could lift the throttling code >>> to BlockBackend, that might solve the problem. >> >> So yes, as long as we have throttling on the BDS level, something may >> always break when having multiple BBs per BDS, because you'd probably >> want throttling to be on the BB level. But lifting that doesn't seem a >> trivial task, and I don't really know whether I want this in this >> series. >> >> Especially considering that right now you cannot have multiple BBs per >> BDS. >> >> All in all: Yes, before we allow multiple BBs per BDS we want >> throttling to be on the BB level. But this is nothing that should be >> done in or for this series, since right now we do not allow multiple >> BBs per BDS. > > I agree that it makes sense to move throttling to the BB level. It's > probably not trivial but I don't think it's too complex either. I can > give it a look once this series has been merged.
Ultimately, I think we want throttling at both levels. I can make the argument that in a cloud, a guest should not be able to consume more than X resources (throttling at the BB, regardless of what BDS tree it is associated with); but I can also argue that I may want to throttle specific BDS (a backing chain with network backing file and local active file: throttle the backing file to limit network traffic, and the guest gets faster as it moves more local; or conversely, a common backing file and one-off guest: throttle the active layer to do performance analysis of the bottlenecks where the guest differs from the common backing layer). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature