On Fri 01-07-11 13:42:58, Kevin Constantine wrote: > On 06/30/2011 12:11 AM, Michal Hocko wrote: > >On Wed 29-06-11 12:32:13, Kevin Constantine wrote: > >>I think cgred makes sense for managing machines where I know what > >>kind of workload to expect. My understanding of it is that cgroups > >>are created ahead of time with cgconfig.conf and then the rules map > >>processes into those cgroups. > > > >I may be wrong because I have never played with %p or %u for group name > >specification but they sound dynamic enough to require on demand cgroups > >creation. > > > > What's the %p %u you're talking about? I haven't seen that syntax > in what I've read.
You can specify a group name based on the process name (%p), pid (%P), user name (%u), uid (%U), group name (%g) and guid (%G). See man cgrules.conf > > >>The problem is that I have no idea what kind of workload to expect > >>on most of these machines. The processes could be named just about > >>anything, and they could come from just about any user. > > > >How do you do that in your code then? Do you have any active monitoring > >running which shuffles jobs around? > > > > Each client machine has a daemon that communicates with a central > scheduler. host configuration is also stored centrally. I can say > something like all HP DL380's will present 16GB and CPU's 0-3 to the > queue. A cgroup will get created with the memory subsystem and the > cpuset subsystem. We'll set memory.limit_in_bytes to "16G", and > cpuset.cpus to 0-3 (we'll also set cpuset.mems to whatever the > parent cgroup has, but that's another issue to discuss). The client > daemon is then responsible for keeping track of what cpu's are > currently pinned and which ones are free. New batch jobs will get a > new cgroup created in /cgroup/cpuset/batchJobs/123456 and have > cpuset.cpus set to the appropriate pinned cpu (or cpu's for a > multithreaded job). The process will be started up in > cpuset:/batchJobs/12345, and memory:/batchJobs cgroups. When a job > completes, cpuset:/batchJobs/12345 gets destroyed. So if IIUC, your batch jobs share the same memory cgroup which should limit all batch jobs while cpus are assigned per cgroups (aka per job). Why do you need to set up physical CPUs? Your workflow sounds more like a CPU bandwidth oriented. You have many jobs that you want to run but you do not want to disturb regular usage of the box, right? Then I would use cpu subsystem and set up 2 groups regular and batch and assign an appropriate share (regular would get higher number) for each of them. Batch jobs would use as much CPU bandwidth as possible (100% of capacity if there is no regular activity and appropriate share if regular+batch requirements are bigger than available) -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic ------------------------------------------------------------------------------ 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
