Yea, unfortunately I don't have a patch to propose at this time. My primary goal was to determine if the value was arbitrary (which you said it was). I'm working around it for now at the higher level by collapsing my cpuset.cpus value into a range: "0-10,20-30,40" That should keep me moving unless someday we happen to have a system with enough logical cpus that it would generate a range string still larger than 100 characters.
On Thu, Jun 26, 2014 at 12:42 PM, Dhaval Giani <dhaval.gi...@gmail.com> wrote: > > > > On Wed, Jun 25, 2014 at 8:03 PM, Justin Israel <justinisr...@gmail.com> > wrote: > >> Hi there, >> >> I had a question about something that produced a really hard-to-track bug. >> I've been using my own python bindings against libcgroup for a while now, >> and it makes heavy use of setting the cpuset.cpus value to limit logical >> cores in transient cgroups. >> >> A bug cropped up where some of our larger hosts were seeing "End of File >> or >> iterator" errors while creating new cgroups. I finally tracked this down >> to >> the following constant: >> >> #define CG_VALUE_MAX 100 >> >> The problem is that I had been passing a comma-separated list logical cpu >> ids to cpuset.cpus, and once this was happening on machines with 128 >> logical cpus, it turned out that libcgroup was truncating the string value >> being set: >> >> i.e., I pass something like this: >> >> "0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63" >> >> And ultimately what libcgroup will set is this: >> >> "0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36\x01" >> >> And then error out. >> >> Strangely though, echoing the full string to cpuset.cpus via the >> filesystem >> interface is perfectly supported and works fine. Is this 100 character >> limit arbitrary? Is there a reason to prevent larger string values from >> being set when it is doesn't seem to be a limit of the filesystem >> interface? >> >> > Yes, it was arbitrary. Mainly because we allocate that much space in > advance. I would happily take a patch that would make that allocation > dynamic, though since these data structures are not long lived, we could > probably change the CG_VALUE_MAX to something that might be more useful. > > Thanks! > Dhaval > ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
