Hello, Aleksa. On Wed, Jun 29, 2016 at 03:10:26PM +1000, Aleksa Sarai wrote: > Maybe I'm misunderstanding what the purpose of pids.events is meant to be. > If it's just meant to be a "hint" to the administrator, then that seems like > an awfully odd way of giving hints (the kernel logging should be enough for > that). If it's meant so that the administrator can make policy decisions, Kernel logging may be an enough hint for a human admin but is an awful mechanism for any programs trying to monitor. > then she won't know if the change in failures happened before or after she > adjusted the limit. > > I also don't see what you mean by "it can be avoided from userland". There's > a race between changing pids.max and a process forking that causes > pids.events to be updated. First of all, a situation where a cgroup hits its limits and then can proceed normally after the limit is lifted would be very rare. Secondly, even in those corner cases, synchronization between config update and event counter doesn't matter. For dynamic adjustments to work, fork failures have to be cleanly recoverable and thus the user can just start monitoring after the config is bumped up - if it fails again, adjust again; otherwise, it's all good. It just doesn't matter. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
