Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Tue, May 12, 2015 at 11:43 PM, Tejun Heo 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Tue, May 12, 2015 at 11:43 PM, Tejun Heo t...@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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Mon, May 11, 2015 at 1:28 PM, Kyungmin Park wrote: > On Sat, May 9, 2015 at 12:25 AM, Tejun Heo 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
2015-05-09 0:25 GMT+09:00 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? 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
2015-05-09 0:25 GMT+09:00 Tejun Heo t...@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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Mon, May 11, 2015 at 1:28 PM, Kyungmin Park kmp...@infradead.org wrote: On Sat, May 9, 2015 at 12:25 AM, Tejun Heo t...@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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Sat, May 9, 2015 at 12:25 AM, Tejun Heo 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Sat, May 9, 2015 at 12:25 AM, Tejun Heo t...@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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Fri, May 8, 2015 at 12:42 AM, Tejun Heo wrote: > Hello, > > On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote: >> From: Kyungmin Park >> >> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
Hello, On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote: > From: Kyungmin Park > > 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
From: Kyungmin Park
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
---
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(_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
From: Kyungmin Park kyungmin.p...@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.p...@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 from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Fri, May 8, 2015 at 12:42 AM, Tejun Heo t...@kernel.org wrote: Hello, On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote: From: Kyungmin Park kyungmin.p...@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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
Hello, On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote: From: Kyungmin Park kyungmin.p...@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 from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
