We didn't want to exec external python programs because that certainly
*does* have bad scalability, terrible error reporting facilities and
need to parse ill defined data formats from stdout, etc. It doesn't
magically solve the complexity, just moves it elsewhere where we have
less ability to tailor it to fit into libvirt's model.
BTW, to clarify, RMD is not wroten by python, it's golang, and it's not just a tool,
it's a running service(agent) on the host, provided RESTful API by unix/TCP socket.
and much more smarter (policy based) then static allocation. Support re-enforcement
and much more smarter (policy based) then static allocation. Support re-enforcement
based on monitoring data (cache usage).
It aimed to be the only one interface for all who want to operation /sys/fs/resctrl, or
even early kernel (4.10) which has no /sys/fs/resctrl (thought MSR).
It not only provide VM but for all kinds of workload/cpu/containers.
BR - Eli
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
