>>> Then it is the same situation if you define a cgroup in cpuset in >>> cgconfig.conf. I plan to do examples and document the configuration nicely. >>> From my point this is the best solution. Is it ok for you? >> >> I would prefer a sane default, such as copy_from_parent, which means, >> we will almost always have a sane default, which works. > > There is no sane default without extensive logic in libcgroup, copy from > parent won't work on cpuset with cpu_exclusive. >
Correct, but I will argue that for most cases, cpu_exclusive is not used, and people expect it to work like they expect other cgroups to work (that is inherit sane values from parent). Let me put it this way, if you are using cpu_exclusive, and using libcgroup at the same time, you oughta know what cpusets are, and how to configure libcgroup. And you are expected to either turn of automatic classification, or configure it with a sane default for your use case. However, not using cpu_exclusive, might mean that you do not know about cpusets, and do not care about them, (And if you do, then the same caveat that applied in the previous case applies to you). In this case, we _have_ to provide sane defaults which is, use all the memory, use all the CPUs. > Current cgconfigparser does simple mkdir for groups, which are not > configured. It is up to the administrator to pre-configure parent groups > if simple mkdir is not enough. > > I think that cgrulesengd should do exactly the same. This is where I do not agree. I believe we made a mistake originally by not setting sane defaults. It has bitten us more than once. While I agree, it is hard to come up with that, we do need both policy as well as mechanism to be setup. Dhaval ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
