Skip to contentSkip to conversation

PM, freezer: Don't thaw when it's intended frozen processes

RFC PATCH In review Kyungmin Park 3 participants 11 messages May 7, 2015 – May 13, 2015

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

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

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?

---

kernel/power/process.c +3 -1
index 564f786..6eed7df 100644
@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#1 lore raw

Hello,

Quoted 3 lines · Kyungmin Park

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.

Quoted 3 lines

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.

Signature · 7 lines
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#2 lore raw
Quoted 11 lines · Tejun Heo

Hello,

Quoted 3 lines · Kyungmin Park

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.

Quoted 7 lines
Quoted 3 lines

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

#3 lore raw

Hello, Kyungmin.

Quoted 11 lines · Kyungmin Park
Quoted 3 lines

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.

Quoted 7 lines

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.

Signature · 7 lines
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#4 lore raw
Quoted 19 lines · Tejun Heo

Hello, Kyungmin.

Quoted 16 lines · Kyungmin Park
Quoted 3 lines

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.

Quoted 7 lines
Quoted 2 lines

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

#9 lore raw
In reply to Tejun Heo

2015-05-09 0:25 GMT+09:00 Tejun Heo <[email protected]>:

Quoted 19 lines

Hello, Kyungmin.

Quoted 16 lines · Kyungmin Park
Quoted 3 lines

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.

Quoted 7 lines
Quoted 2 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#5 lore raw
In reply to Kyungmin Park
Quoted 23 lines · Kyungmin Park
Quoted 22 lines · Tejun Heo

Hello, Kyungmin.

Quoted 18 lines · Kyungmin Park
Quoted 3 lines

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.

Quoted 7 lines
Quoted 4 lines

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.

Quoted 5 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#10 lore raw
In reply to Krzysztof Kozlowski
Quoted 20 lines · Krzysztof Kozlowski
Quoted 4 lines

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
-----
Quoted 2 lines

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.

Signature · 7 lines
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#6 lore raw
In reply to Kyungmin Park

Hello,

Quoted 4 lines · Kyungmin Park
Quoted 2 lines

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.

Signature · 7 lines
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#7 lore raw
Quoted 11 lines · Tejun Heo

Hello,

Quoted 4 lines · Kyungmin Park
Quoted 2 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#8 lore raw
Quoted 4 lines · Kyungmin Park

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.

Signature · 7 lines
tejun

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