> Putting a reasonable limit on jobs that are expected to run only for a > limited amount of time, with a limited amount of total resources. For fork is an almost irrelevant resource. Address space (ie memory), file handles and the like are actual constrained resources. I can't help thinking this is focussing on a completely irrelevant cornercase issue. It belongs as part of a general resource limiting cgroup that also deals with memory, I/O and the like. In fact most of these resources are a balancing act. Who cares if you have 10,000 threads. We can handle that without trying. 10,000 different mappings is a whole different ball game, and 100,000 file handles in some configurations might also matter. In short in your specific environment a fork runaway is a symptom you can use to detect and sometimes halt the failure case. It's not the actual resource problem and it doesn't solve the general case. > Similar existing feature: RLIMIT_CPU. Millions of users have it in > their kernels, but nobody uses it nowadays. And it's not even > optional. It's required by the standards, and basically unmeasurable overhead. > Btw. I have no problem with maintaining this patch (and a whole bunch > of others) in my proprietary git repository at work forever. They're > very useful for my employer. I'm just trying to be a good citizen by > sharing them. Sure - I'm just not seeing that a whole separate cgroup for it is appropriate or a good plan. Anyone doing real resource management needs the rest of the stuff anyway. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
