On Mon, Oct 11, 2010 at 9:42 AM, Daniel Lezcano <daniel.lezc...@free.fr> wrote: > On 10/11/2010 08:48 AM, richard -rw- weinberger wrote: >> >> Hi list, >> >> I've a question on freezer.c. >> In freeze_unfreeze() is a while(1) loop which write()s "FROZEN" or >> "THAWED" until read() returns the same. >> Why do we need this loop? >> It looks like a hack to me. > > > The freezer documentation specifies: > state (because of the cgroup state 'freezeing), making the cgroup to > converge to the frozen state. > > When we check the cgroup is frozen, the kernel look at this task list and > find the new child process which is not yet frozen and will return > 'freezing' instead of "frozen'. Freezing the cgroup again will freeze this > missing task. > > "It's important to note that freezing can be incomplete. In that case we > return EBUSY. This means that some tasks in the cgroup are busy doing > something that prevents us from completely freezing the cgroup at this time. > After EBUSY, the cgroup will remain partially frozen -- reflected by > freezer.state reporting "FREEZING" when read. The state will remain > "FREEZING" until one of these things happens: > > 1) Userspace cancels the freezing operation by writing "THAWED" to the > freezer.state file > > 2) Userspace retries the freezing operation by writing "FROZEN" to the > freezer.state file (writing "FREEZING" is not legal and returns EINVAL) > > 3) The tasks that blocked the cgroup from entering the "FROZEN" state > disappear from the cgroup's set of tasks." > > The loop in the code is for the case (2). > > Let me clarify: > > (1) When we freeze a cgroup, the kernel browse the cgroup's tasks list and > will send a fake signal to each of them. > > But the places where the hooks are in the kernel code (fork and exit), make > possible to send this signal to a task while it is forking and the child > process is not yet in the cgroup's task list. > > The forking task will go to the frozen state right after returning from the > fork but the child task won't because it didn't receive the fake signal. > > If this child process forks again, the new child will automatically go to > the frozen state (because of the cgroup state 'freezing), making the cgroup > to converge to the frozen state. > > When we check the cgroup is frozen, the kernel look at this task list and > find the new child process which is not yet frozen and will return > 'freezing' instead of "frozen'. Freezing the cgroup again will freeze this > missing task. > > > (2) It's possible to freeze a cgroup while it is in important IO, aka > 'uninteruptible state', so we won't be able to freeze immediately and we > have to retry. > > > > These both cases happen rarely, so most of the time, one iteration in the > loop is enough to freeze the container. >
Thanks for the clarification! :-) -- Thanks, //richard ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
