Hi, Everyone,
I've seen a new set of patches from Dan Smith, which implement cgroup support
for libvirt. While the patches seem simple, there are some issues that have been
pointed out in the posting itself.
I hope that libvirt will switch over (may be after your concerns are addressed
and definitely in the longer run) to using libcgroups rather than having an
internal implementation of cgroups. The advantages of switching over would be
using the functionality that libcgroup already provides
libcgroups (
libcg.sf.net) provides
1. Ability to configure and mount cgroups and controllers via initscripts and a
configuration file
2. An API to control and read cgroups information
3. Thread safety around API calls
4. Daemons to automatically classify a task based on a certain set of rules
5. API to extract current cgroup classification (where is the task currently in
the cgroup hierarchy)
While re-implementing might sound like a cool thing to do, here are the drawbacks
1. It leads to code duplication and reduces code reuse
2. It leads to confused users
I understand that in the past there has been a perception that libcgroups might
not yet be ready, because we did not have ABI stability built into the library
and the header file had old comments about things changing. I would urge the
group to look at the current implementation of libcgroups (look at v0.32) and
help us
1. Fix any issues you see or point them to us
2. Add new API or request for new API that can help us integrate better with libvirt
--
Balbir