Mark Dixon <[email protected]> writes: > cgroup control of memory isn't in soge as far as I know, only control > of process placement.
Yes, there's currently only an attempt to use cpusets, for various reasons. > I've not maintained those patches and got them merged, because I ran > into problems with an interaction between the memory cgroup controller > and the Lustre filesystem on centos6 clients. Essentially, attempts to > delete the cgroup at job end would cause the execd to hang in a call > to rmdir. Perhaps I'll try again and see if centos7+lustre is any > better when we get our next machine. I still have that merged, but I didn't want to add more stuff that might have to be changed incompatibly later (see below). > What's your motivation: is it more accurate measurement of memory > usage? Dave did some work a while back and so the existing soge > functionality is pretty good, with one small modification. If you > ditch the bit in source/daemons/shepherd/setrlimits.c that sets > RLIMIT_AS, all memory control will be based on a realistic measurement > by the kernel - I don't understand. If you drop the rlimit, the only control of memory is qmaster killing when the measured usage exceeds the h_vmem. In particular, the application can't fail gracefully if it tries to use too much memory, and it can cause OOM by allocating fast enough, possibly getting another job killed that is within limits. (One of the rubbish things about cgroups is that you can't fail gracefully on memory allocation. Another is the performance penalty, though I haven't measured that for relevant applications.) What is the "realistic measurement by the kernel"? > but all enforcement will be done via a periodic poll > by the execd. We've been running like that for ages very happily: I > tried to get a patch merged that drops RLIMIT_AS, but it didn't make > the cut. I wasn't convinced by the interface, didn't think it was relevant without the memory cgroup, and it alters the comm/spool protocol, but I didn't have anything against it in principle. The whole cgroups thing is a horrible moving target. I think it was a mistake to bake in support, rather than providing appropriate hooks like SLURM's, rather than the re-write I'd started on. That's not likely to get done, though, unless someone else takes over, especially as I couldn't test it properly. People should probably move to SLURM for better resource management. _______________________________________________ SGE-discuss mailing list [email protected] https://arc.liv.ac.uk/mailman/listinfo/sge-discuss
