[RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

From: Kyungmin Park <kyungmin.park@samsung.com>

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 <kyungmin.park@samsung.com>
---
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);
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

From: Kyungmin Park <kyungmin.park@samsung.com>

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 <kyungmin.park@samsung.com>
---
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);
 

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

Hello,

On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote:
> From: Kyungmin Park <kyungmin.park@samsung.com>
> 
> 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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

Hello,

On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote:
> From: Kyungmin Park <kyungmin.park@samsung.com>
> 
> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

On Fri, May 8, 2015 at 12:42 AM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote:
>> From: Kyungmin Park <kyungmin.park@samsung.com>
>>
>> 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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

On Fri, May 8, 2015 at 12:42 AM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote:
>> From: Kyungmin Park <kyungmin.park@samsung.com>
>>
>> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

On Sat, May 9, 2015 at 12:25 AM, Tejun Heo <tj@kernel.org> 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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

On Sat, May 9, 2015 at 12:25 AM, Tejun Heo <tj@kernel.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

On Mon, May 11, 2015 at 1:28 PM, Kyungmin Park <kmpark@infradead.org> wrote:
> On Sat, May 9, 2015 at 12:25 AM, Tejun Heo <tj@kernel.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

On Mon, May 11, 2015 at 1:28 PM, Kyungmin Park <kmpark@infradead.org> wrote:
> On Sat, May 9, 2015 at 12:25 AM, Tejun Heo <tj@kernel.org> 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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

On Tue, May 12, 2015 at 11:43 PM, Tejun Heo <tj@kernel.org> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Kyungmin Park]

On Tue, May 12, 2015 at 11:43 PM, Tejun Heo <tj@kernel.org> 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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Krzysztof Kozlowski]

2015-05-09 0:25 GMT+09:00 Tejun Heo <tj@kernel.org>:
> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Krzysztof Kozlowski]

2015-05-09 0:25 GMT+09:00 Tejun Heo <tj@kernel.org>:
> 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

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes

[Tejun Heo]

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