Re: [lxc-devel] Question on freezer.c
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. -- 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
Re: [lxc-devel] Question on freezer.c
On 10/11/2010 09:42 AM, Daniel Lezcano 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: > > Sorry I did an unwanted copy-paste at this place with the end of this email :) > "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. > > -- > 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 > > -- 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
Re: [lxc-devel] Question on freezer.c
On Mon, Oct 11, 2010 at 9:42 AM, Daniel Lezcano 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
