From: Kyungmin Park <[email protected]>
Some platform uses freezer cgroup for speicial purpose to schedule out some applications. but after suspend & resume, these processes are thawed and running.
but it's inteneded and don't need to thaw it.
To avoid it, does it possible to modify resume code and don't thaw it when resume? does it resonable?
Signed-off-by: Kyungmin Park <[email protected]>
---
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 564f786..6eed7df 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -202,7 +202,9 @@ void thaw_processes(void)
for_each_process_thread(g, p) {
/* No other threads should have PF_SUSPEND_TASK set */
WARN_ON((p != curr) && (p->flags & PF_SUSPEND_TASK));
- __thaw_task(p);
+ /* Don't need to thaw when it's already frozen by userspace */
+ if (!cgroup_freezing(p))
+ __thaw_task(p);
}
read_unlock(&tasklist_lock);
Hello,
On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote:
> From: Kyungmin Park <[email protected]>
>
> Some platform uses freezer cgroup for speicial purpose to schedule out some applications. but after suspend & resume, these processes are thawed and running.
They shouldn't be able to leave the freezer tho. Resuming does wake
up all tasks but freezing() test would still evaulate to true for the
ones frozen by cgroup freezer and they will stay inside the freezer.
> but it's inteneded and don't need to thaw it.
>
> To avoid it, does it possible to modify resume code and don't thaw it when resume? does it resonable?
I need to think more about it but as an *optimization* we can add
freezing() test before actually waking tasks up during resume, but can
you please clarify what you're seeing?
Thanks.
--
tejun
On Fri, May 8, 2015 at 12:42 AM, Tejun Heo <[email protected]> wrote:
> Hello,
>
> On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote:
>> From: Kyungmin Park <[email protected]>
>>
>> Some platform uses freezer cgroup for speicial purpose to schedule out some applications. but after suspend & resume, these processes are thawed and running.
>
> They shouldn't be able to leave the freezer tho. Resuming does wake
> up all tasks but freezing() test would still evaulate to true for the
> ones frozen by cgroup freezer and they will stay inside the freezer.
>
>> but it's inteneded and don't need to thaw it.
>>
>> To avoid it, does it possible to modify resume code and don't thaw it when resume? does it resonable?
>
> I need to think more about it but as an *optimization* we can add
> freezing() test before actually waking tasks up during resume, but can
> you please clarify what you're seeing?
The mobile application has life cycle and one of them is 'suspend'
state. it's different from 'pause' or 'background'.
if there are some application and enter go 'suspend' state. all
behaviors are stopped and can't do anything. right it's suspended. but
after system suspend & resume, these application is thawed and
running. even though system know it's suspended.
We made some test application, print out some message within infinite
loop. when it goes 'suspend' state. nothing is print out. but after
system suspend & resume, it prints out again. that's not desired
behavior. and want to address it.
frozen user processes should be remained as frozen while system
suspend & resume.
Thank you,
Kyungmin Park
Hello, Kyungmin.
On Fri, May 08, 2015 at 09:04:26AM +0900, Kyungmin Park wrote:
> > I need to think more about it but as an *optimization* we can add
> > freezing() test before actually waking tasks up during resume, but can
> > you please clarify what you're seeing?
>
> The mobile application has life cycle and one of them is 'suspend'
> state. it's different from 'pause' or 'background'.
> if there are some application and enter go 'suspend' state. all
> behaviors are stopped and can't do anything. right it's suspended. but
> after system suspend & resume, these application is thawed and
> running. even though system know it's suspended.
>
> We made some test application, print out some message within infinite
> loop. when it goes 'suspend' state. nothing is print out. but after
> system suspend & resume, it prints out again. that's not desired
> behavior. and want to address it.
>
> frozen user processes should be remained as frozen while system
> suspend & resume.
Yes, they should and I'm not sure why what you're saying is happening
because freezing() test done from the frozen tasks themselves should
keep them in the freezer. Which kernel version did you test? Can you
please verify it against a recent kernel?
Thanks.
--
tejun
On Sat, May 9, 2015 at 12:25 AM, Tejun Heo <[email protected]> wrote:
> Hello, Kyungmin.
>
> On Fri, May 08, 2015 at 09:04:26AM +0900, Kyungmin Park wrote:
>> > I need to think more about it but as an *optimization* we can add
>> > freezing() test before actually waking tasks up during resume, but can
>> > you please clarify what you're seeing?
>>
>> The mobile application has life cycle and one of them is 'suspend'
>> state. it's different from 'pause' or 'background'.
>> if there are some application and enter go 'suspend' state. all
>> behaviors are stopped and can't do anything. right it's suspended. but
>> after system suspend & resume, these application is thawed and
>> running. even though system know it's suspended.
>>
>> We made some test application, print out some message within infinite
>> loop. when it goes 'suspend' state. nothing is print out. but after
>> system suspend & resume, it prints out again. that's not desired
>> behavior. and want to address it.
>>
>> frozen user processes should be remained as frozen while system
>> suspend & resume.
>
> Yes, they should and I'm not sure why what you're saying is happening
> because freezing() test done from the frozen tasks themselves should
> keep them in the freezer. Which kernel version did you test? Can you
> please verify it against a recent kernel?
The kernel 3.10 is not working as expected, but right the latest
kernel is working correctly.
I see I'll check what's different and which are modified.
Thank you,
Kyungmin Park
2015-05-09 0:25 GMT+09:00 Tejun Heo <[email protected]>:
> Hello, Kyungmin.
>
> On Fri, May 08, 2015 at 09:04:26AM +0900, Kyungmin Park wrote:
>> > I need to think more about it but as an *optimization* we can add
>> > freezing() test before actually waking tasks up during resume, but can
>> > you please clarify what you're seeing?
>>
>> The mobile application has life cycle and one of them is 'suspend'
>> state. it's different from 'pause' or 'background'.
>> if there are some application and enter go 'suspend' state. all
>> behaviors are stopped and can't do anything. right it's suspended. but
>> after system suspend & resume, these application is thawed and
>> running. even though system know it's suspended.
>>
>> We made some test application, print out some message within infinite
>> loop. when it goes 'suspend' state. nothing is print out. but after
>> system suspend & resume, it prints out again. that's not desired
>> behavior. and want to address it.
>>
>> frozen user processes should be remained as frozen while system
>> suspend & resume.
>
> Yes, they should and I'm not sure why what you're saying is happening
> because freezing() test done from the frozen tasks themselves should
> keep them in the freezer. Which kernel version did you test? Can you
> please verify it against a recent kernel?
Hi,
I tested it on v4.1-rc3 and next-20150508.
Task was moved to frozen cgroup:
-----
root@localhost:/sys/fs/cgroup/freezer/frozen# grep . *
cgroup.clone_children:0
cgroup.procs:2750
freezer.parent_freezing:0
freezer.self_freezing:1
freezer.state:FROZEN
notify_on_release:0
tasks:2750
tasks:2773
-----
Unfortunately during system resume the process was woken up. The "if
(frozen(p))" check was true. Is it expected behaviour?
Best regards,
Krzysztof
On Mon, May 11, 2015 at 1:28 PM, Kyungmin Park <[email protected]> wrote:
> On Sat, May 9, 2015 at 12:25 AM, Tejun Heo <[email protected]> wrote:
>> Hello, Kyungmin.
>>
>> On Fri, May 08, 2015 at 09:04:26AM +0900, Kyungmin Park wrote:
>>> > I need to think more about it but as an *optimization* we can add
>>> > freezing() test before actually waking tasks up during resume, but can
>>> > you please clarify what you're seeing?
>>>
>>> The mobile application has life cycle and one of them is 'suspend'
>>> state. it's different from 'pause' or 'background'.
>>> if there are some application and enter go 'suspend' state. all
>>> behaviors are stopped and can't do anything. right it's suspended. but
>>> after system suspend & resume, these application is thawed and
>>> running. even though system know it's suspended.
>>>
>>> We made some test application, print out some message within infinite
>>> loop. when it goes 'suspend' state. nothing is print out. but after
>>> system suspend & resume, it prints out again. that's not desired
>>> behavior. and want to address it.
>>>
>>> frozen user processes should be remained as frozen while system
>>> suspend & resume.
>>
>> Yes, they should and I'm not sure why what you're saying is happening
>> because freezing() test done from the frozen tasks themselves should
>> keep them in the freezer. Which kernel version did you test? Can you
>> please verify it against a recent kernel?
>
> The kernel 3.10 is not working as expected, but right the latest
> kernel is working correctly.
Please ignore it. test is wrong and it's not working, see Krzysztof Mail.
>
> I see I'll check what's different and which are modified.
>
> Thank you,
> Kyungmin Park
On Mon, May 11, 2015 at 03:33:10PM +0900, Krzysztof Kozlowski wrote:
> > Yes, they should and I'm not sure why what you're saying is happening
> > because freezing() test done from the frozen tasks themselves should
> > keep them in the freezer. Which kernel version did you test? Can you
> > please verify it against a recent kernel?
>
> I tested it on v4.1-rc3 and next-20150508.
>
> Task was moved to frozen cgroup:
> -----
> root@localhost:/sys/fs/cgroup/freezer/frozen# grep . *
> cgroup.clone_children:0
> cgroup.procs:2750
> freezer.parent_freezing:0
> freezer.self_freezing:1
> freezer.state:FROZEN
> notify_on_release:0
> tasks:2750
> tasks:2773
> -----
>
> Unfortunately during system resume the process was woken up. The "if
> (frozen(p))" check was true. Is it expected behaviour?
It isn't optimal but doesn't break anything either. Whether a task
stays in the freezer or not is solely decided by freezing() test by
the task itself. Being woken up spuriously doesn't break anything.
Thanks.
--
tejun
Hello,
On Mon, May 11, 2015 at 04:47:14PM +0900, Kyungmin Park wrote:
> > The kernel 3.10 is not working as expected, but right the latest
> > kernel is working correctly.
>
> Please ignore it. test is wrong and it's not working, see Krzysztof Mail.
So, I just tested and it does work as expected. What Krzysztof said
is the same thing that I said in the first reply. The tasks will be
woken up but won't leave freezer. Please re-test.
Thanks.
--
tejun
On Tue, May 12, 2015 at 11:43 PM, Tejun Heo <[email protected]> wrote:
> Hello,
>
> On Mon, May 11, 2015 at 04:47:14PM +0900, Kyungmin Park wrote:
>> > The kernel 3.10 is not working as expected, but right the latest
>> > kernel is working correctly.
>>
>> Please ignore it. test is wrong and it's not working, see Krzysztof Mail.
>
> So, I just tested and it does work as expected. What Krzysztof said
> is the same thing that I said in the first reply. The tasks will be
> woken up but won't leave freezer. Please re-test.
Right, it's still in freezer, just one time scheduling is happened.
and enter freeze state again.
do you think can we avoid it or it's sub-optimal to do as patch?
Thank you,
Kyungmin Park
On Wed, May 13, 2015 at 09:42:47AM +0900, Kyungmin Park wrote:
> Right, it's still in freezer, just one time scheduling is happened.
> and enter freeze state again.
>
> do you think can we avoid it or it's sub-optimal to do as patch?
I mean, it's suboptimal. I'm not sure it actually matters tho. If it
matters, please feel free to submit a patch with proper rationale.
Please just be careful so that we don't miss sending out wakeup in
case we race against thawing.
Thanks.
--
tejun