On Fri, Jun 24, 2011 at 7:40 AM, Kevin Constantine <kevin.constant...@disneyanimation.com> wrote: > On 06/23/2011 05:51 PM, Balbir Singh wrote: >>> >>> Once I have a cgroup struct from cgroup_get_cgroup(), it would be helpful >>> to >>> know what controllers it contains. I can get a cgroup_controller struct >>> with cgroup_get_controller(), but I need to know the controller name is >>> to >>> get that. >>> >>> Is there a method to return the list of controller names (or controller >>> structs) that are in a cgroup? >> >> I see what you mean, this is the tricky bit and probably an area where >> we could improve. We assume the programmer knows what controller is >> being dealt with (since the control file names are controller >> specific). For example, lets say we want CPU control, then one could >> use >> >> cgroup_get_controller(cgroup, "cpu") to return the controller and then >> use the controller further to read values >> >> If we wanted to set any value, we know the file to set (say >> cpu.shares), then we do >> >> cgroup_add_controller(cgroup, "cpu") and set values in it >> >> I hope that helps, >> > > Yeah, it helps me to understand what is expected of the end developer, > versus what will be handled in the libcg api. I'm just trying to get my > head wrapped around how you all envision the api being used. >
I am glad I was able to help, we'll try and simplify the API further for sure. >> FYI: We need to work on a layer 2 API that abstracts all these details >> and creates more meaningful names like set_cpu_shares(), >> get_cpu_shares(), etc. >> >> If you don't mind, can I ask how you are using libcgroup, what is the use >> case? >> > > We're using cgroups in our render environment to pin batch jobs and their > child processes to individual cpu's to avoid processes hopping around to > different cores and flushing their caches. Basically each batch job gets > its own cgroup with the cpuset controller and we allocate a single cpu to > that cgroup. > > We're also using them to run batch jobs on our interactive workstations > without impacting the end user. We're carving off a few cores and a few > GB's of RAM from each workstation to run batch jobs on throughout the day. > cool! nice use of partitioning > Basically the batch scheduler is dynamically creating and destroying cgroups > pretty regularly. I wrote code to do all of that and then realized that > libcgroup exists, so now I'm going back through and refactoring to use the > api as much as possible. > Wonderful! Please do share your pain points and experiences > What I found when writing the initial code was that error checking was a > giant pain in the neck, especially when removing a cgroup. I'm hoping that > the api will abstract most of that away for me. I'm also hoping that I'll > be able to reduce some of the hard-coded assumptions I originally made (like > we're mounting at /cgroup for example) > > Thanks for the help so far. Your welcome, so based on the feedback you want 1. Simpler API 2. Simpler Error handling Balbir ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
