Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Tue, 9 Aug 2005, Nigel Cunningham wrote: > > No it wont. A process that has notifications to process should do that > > before being put into the freezer. Only after the notification list is > > empty will the process be notified and as long as the notification is > > pending no second notification should happen. > > Sorry I wasn't clear. I was thinking of the case where a broken process > doesn't process its todo list. (May it never be, but still...). How do > we find out which one is broken? We need to traverse the todo list of > every process, checking for outstanding freeze requests. If a process does not handle its todo then you cannot freeze the process at all. Something very bd is going on. The current version gives up if a process cannot be frozen. This is still doing the same. > Your reply leads me to another issue. It seems to me that you shouldn't > wait until the todo list is empty before putting the freeze request on > the todo list. If the todo list is ever used for something where it > becomes hot, you might never see the todo list empty before your > timeout, and freezing will be unreliable. Even if you do see it empty > and insert your freeze request, it might be that more work is added > afterwards, so you may as well just add the request whether or not the > queue is empty. Yes other tasks can be put on the notifier later. But the freeze notifier was first so the task is put to sleep and will run the other notifiers upon wakeup. The check is still okay. No additional notification should be added if the freeze notifier is already queued. > > I am not sure how to sort that out. I guess post the current patches that > > you got and then we see how to continue from there. > > Will do shortly. Just have to go talk to my boss first :> (Separate > issue). The patch you sent looks fine to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Tue, 9 Aug 2005, Nigel Cunningham wrote: No it wont. A process that has notifications to process should do that before being put into the freezer. Only after the notification list is empty will the process be notified and as long as the notification is pending no second notification should happen. Sorry I wasn't clear. I was thinking of the case where a broken process doesn't process its todo list. (May it never be, but still...). How do we find out which one is broken? We need to traverse the todo list of every process, checking for outstanding freeze requests. If a process does not handle its todo then you cannot freeze the process at all. Something very bd is going on. The current version gives up if a process cannot be frozen. This is still doing the same. Your reply leads me to another issue. It seems to me that you shouldn't wait until the todo list is empty before putting the freeze request on the todo list. If the todo list is ever used for something where it becomes hot, you might never see the todo list empty before your timeout, and freezing will be unreliable. Even if you do see it empty and insert your freeze request, it might be that more work is added afterwards, so you may as well just add the request whether or not the queue is empty. Yes other tasks can be put on the notifier later. But the freeze notifier was first so the task is put to sleep and will run the other notifiers upon wakeup. The check is still okay. No additional notification should be added if the freeze notifier is already queued. I am not sure how to sort that out. I guess post the current patches that you got and then we see how to continue from there. Will do shortly. Just have to go talk to my boss first : (Separate issue). The patch you sent looks fine to me. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
(Sorry everyone else for emailing you too. I'm only doing so to honour
the convention of not removing people from replies.)
Hi Christoph.
As I look at the patch in preparation for sending it, I don't think I
really changed anything significant. (I didn't address the issues I
mentioned in the previous email).
The only thing I think might be worth mentioning is that I added
freeze_processes and thaw_processes declarations to
include/linux/suspend.h. I got warnings without them there - perhaps,
though, it's just due to differences in Suspend2.
Having said this, I promised to send you my version, so I've inlined it
below. As you'll see, I'm making some changes just to minimise the
differences with swsusp.
Regards,
Nigel
Documentation/power/kernel_threads.txt | 10 +-
Documentation/power/swsusp.txt |5 -
include/linux/sched.h |1
kernel/power/process.c | 114 ++---
4 files changed, 72 insertions(+), 58 deletions(-)
diff -ruNp 992-suspend_fix.patch-old/Documentation/power/kernel_threads.txt
992-suspend_fix.patch-new/Documentation/power/kernel_threads.txt
--- 992-suspend_fix.patch-old/Documentation/power/kernel_threads.txt
2005-08-08 17:23:31.0 +1000
+++ 992-suspend_fix.patch-new/Documentation/power/kernel_threads.txt
2005-08-09 08:11:41.0 +1000
@@ -4,15 +4,15 @@ KERNEL THREADS
Freezer
Upon entering a suspended state the system will freeze all
-tasks. This is done by delivering pseudosignals. This affects
-kernel threads, too. To successfully freeze a kernel thread
-the thread has to check for the pseudosignal and enter the
-refrigerator. Code to do this looks like this:
+tasks. This is done by making all processes execute a notifier.
+This affects kernel threads, too. To successfully freeze a kernel thread
+the thread has to check for the notifications and call the notifier
+chain for the process. Code to do this looks like this:
do {
hub_events();
wait_event_interruptible(khubd_wait,
!list_empty(_event_list));
- try_to_freeze();
+ try_todo_list();
} while (!signal_pending(current));
from drivers/usb/core/hub.c::hub_thread()
diff -ruNp 992-suspend_fix.patch-old/Documentation/power/swsusp.txt
992-suspend_fix.patch-new/Documentation/power/swsusp.txt
--- 992-suspend_fix.patch-old/Documentation/power/swsusp.txt2005-08-08
17:23:31.0 +1000
+++ 992-suspend_fix.patch-new/Documentation/power/swsusp.txt2005-08-09
08:11:41.0 +1000
@@ -155,7 +155,8 @@ should be sent to the mailing list avail
website, and not to the Linux Kernel Mailing List. We are working
toward merging suspend2 into the mainline kernel.
-Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
+Q: A kernel thread must work on the todo list (call 'run_todo_list')
+to enter the refrigerator.
I found some kernel threads that don't do it, and they don't freeze
so the system can't sleep. Is this a known behavior?
@@ -164,7 +165,7 @@ place where the thread is safe to be fro
should be held at that point and it must be safe to sleep there), and
add:
- try_to_freeze();
+ try_todo_list();
If the thread is needed for writing the image to storage, you should
instead set the PF_NOFREEZE process flag when creating the thread (and
diff -ruNp 992-suspend_fix.patch-old/include/linux/sched.h
992-suspend_fix.patch-new/include/linux/sched.h
--- 992-suspend_fix.patch-old/include/linux/sched.h 2005-08-09
11:17:49.0 +1000
+++ 992-suspend_fix.patch-new/include/linux/sched.h 2005-08-09
08:11:41.0 +1000
@@ -835,7 +835,6 @@ do { if (atomic_dec_and_test(&(tsk)->usa
#define PF_MEMALLOC0x0800 /* Allocating memory */
#define PF_FLUSHER 0x1000 /* responsible for disk writeback */
#define PF_USED_MATH 0x2000 /* if unset the fpu must be initialized
before use */
-#define PF_FREEZE 0x4000 /* this task is being frozen for
suspend now */
#define PF_NOFREEZE0x8000 /* this thread should not be frozen */
#define PF_FROZEN 0x0001 /* frozen for system suspend */
#define PF_FSTRANS 0x0002 /* inside a filesystem transaction */
diff -ruNp 992-suspend_fix.patch-old/kernel/power/process.c
992-suspend_fix.patch-new/kernel/power/process.c
--- 992-suspend_fix.patch-old/kernel/power/process.c2005-08-09
11:17:48.0 +1000
+++ 992-suspend_fix.patch-new/kernel/power/process.c2005-08-09
11:10:59.0 +1000
@@ -61,6 +61,11 @@ extern void suspend_relinquish_console(v
static void freeze_lru(void);
extern void thaw_lru(void);
+DECLARE_COMPLETION(kernelspace_thaw);
+DECLARE_COMPLETION(userspace_thaw);
+static atomic_t nr_userspace_frozen;
+static atomic_t nr_kernelspace_frozen;
+
/*
* to_be_frozen
*
@@ -72,7 +77,7 @@ extern void thaw_lru(void);
static int to_be_frozen(struct task_struct * p,
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi. On Tue, 2005-08-09 at 12:01, Christoph Lameter wrote: > On Tue, 9 Aug 2005, Nigel Cunningham wrote: > > > Just to let you know that I have it working with Suspend2. One thing I > > am concerned about is that we still need a way of determining whether a > > process has been signalled but not yet frozen. At the moment you just > > check p->todo, but if/when other functionality begins to use the todo > > list, this will be unreliable. > > > > No it wont. A process that has notifications to process should do that > before being put into the freezer. Only after the notification list is > empty will the process be notified and as long as the notification is > pending no second notification should happen. Sorry I wasn't clear. I was thinking of the case where a broken process doesn't process its todo list. (May it never be, but still...). How do we find out which one is broken? We need to traverse the todo list of every process, checking for outstanding freeze requests. Your reply leads me to another issue. It seems to me that you shouldn't wait until the todo list is empty before putting the freeze request on the todo list. If the todo list is ever used for something where it becomes hot, you might never see the todo list empty before your timeout, and freezing will be unreliable. Even if you do see it empty and insert your freeze request, it might be that more work is added afterwards, so you may as well just add the request whether or not the queue is empty. Of course if you address this, you then have the problem that the calling routine hammers on routines until they enter the fridge, you can end up with multiple freeze requests per process. That could be addressed by splitting it into two loops - the first adds the todo work for each thread to be frozen, and the second wakes them until they process the notification. I reckon that we shouldn't need to wake them repeatedly like this, but I've never taken the time to see why a process could need multiple wakeups. (I believe it's not bogus). > > I'm happy to supply the patches I'm using if you want to compare. (I > > retained the other freezer improvements, so it wouldn't just be bug > > fixes against your patches). > > I am not sure how to sort that out. I guess post the current patches that > you got and then we see how to continue from there. Will do shortly. Just have to go talk to my boss first :> (Separate issue). Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Tue, 9 Aug 2005, Nigel Cunningham wrote: > Just to let you know that I have it working with Suspend2. One thing I > am concerned about is that we still need a way of determining whether a > process has been signalled but not yet frozen. At the moment you just > check p->todo, but if/when other functionality begins to use the todo > list, this will be unreliable. > No it wont. A process that has notifications to process should do that before being put into the freezer. Only after the notification list is empty will the process be notified and as long as the notification is pending no second notification should happen. > I'm happy to supply the patches I'm using if you want to compare. (I > retained the other freezer improvements, so it wouldn't just be bug > fixes against your patches). I am not sure how to sort that out. I guess post the current patches that you got and then we see how to continue from there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi. Just to let you know that I have it working with Suspend2. One thing I am concerned about is that we still need a way of determining whether a process has been signalled but not yet frozen. At the moment you just check p->todo, but if/when other functionality begins to use the todo list, this will be unreliable. I'm happy to supply the patches I'm using if you want to compare. (I retained the other freezer improvements, so it wouldn't just be bug fixes against your patches). Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi. Just to let you know that I have it working with Suspend2. One thing I am concerned about is that we still need a way of determining whether a process has been signalled but not yet frozen. At the moment you just check p-todo, but if/when other functionality begins to use the todo list, this will be unreliable. I'm happy to supply the patches I'm using if you want to compare. (I retained the other freezer improvements, so it wouldn't just be bug fixes against your patches). Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Tue, 9 Aug 2005, Nigel Cunningham wrote: Just to let you know that I have it working with Suspend2. One thing I am concerned about is that we still need a way of determining whether a process has been signalled but not yet frozen. At the moment you just check p-todo, but if/when other functionality begins to use the todo list, this will be unreliable. No it wont. A process that has notifications to process should do that before being put into the freezer. Only after the notification list is empty will the process be notified and as long as the notification is pending no second notification should happen. I'm happy to supply the patches I'm using if you want to compare. (I retained the other freezer improvements, so it wouldn't just be bug fixes against your patches). I am not sure how to sort that out. I guess post the current patches that you got and then we see how to continue from there. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi. On Tue, 2005-08-09 at 12:01, Christoph Lameter wrote: On Tue, 9 Aug 2005, Nigel Cunningham wrote: Just to let you know that I have it working with Suspend2. One thing I am concerned about is that we still need a way of determining whether a process has been signalled but not yet frozen. At the moment you just check p-todo, but if/when other functionality begins to use the todo list, this will be unreliable. No it wont. A process that has notifications to process should do that before being put into the freezer. Only after the notification list is empty will the process be notified and as long as the notification is pending no second notification should happen. Sorry I wasn't clear. I was thinking of the case where a broken process doesn't process its todo list. (May it never be, but still...). How do we find out which one is broken? We need to traverse the todo list of every process, checking for outstanding freeze requests. Your reply leads me to another issue. It seems to me that you shouldn't wait until the todo list is empty before putting the freeze request on the todo list. If the todo list is ever used for something where it becomes hot, you might never see the todo list empty before your timeout, and freezing will be unreliable. Even if you do see it empty and insert your freeze request, it might be that more work is added afterwards, so you may as well just add the request whether or not the queue is empty. Of course if you address this, you then have the problem that the calling routine hammers on routines until they enter the fridge, you can end up with multiple freeze requests per process. That could be addressed by splitting it into two loops - the first adds the todo work for each thread to be frozen, and the second wakes them until they process the notification. I reckon that we shouldn't need to wake them repeatedly like this, but I've never taken the time to see why a process could need multiple wakeups. (I believe it's not bogus). I'm happy to supply the patches I'm using if you want to compare. (I retained the other freezer improvements, so it wouldn't just be bug fixes against your patches). I am not sure how to sort that out. I guess post the current patches that you got and then we see how to continue from there. Will do shortly. Just have to go talk to my boss first : (Separate issue). Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
(Sorry everyone else for emailing you too. I'm only doing so to honour
the convention of not removing people from replies.)
Hi Christoph.
As I look at the patch in preparation for sending it, I don't think I
really changed anything significant. (I didn't address the issues I
mentioned in the previous email).
The only thing I think might be worth mentioning is that I added
freeze_processes and thaw_processes declarations to
include/linux/suspend.h. I got warnings without them there - perhaps,
though, it's just due to differences in Suspend2.
Having said this, I promised to send you my version, so I've inlined it
below. As you'll see, I'm making some changes just to minimise the
differences with swsusp.
Regards,
Nigel
Documentation/power/kernel_threads.txt | 10 +-
Documentation/power/swsusp.txt |5 -
include/linux/sched.h |1
kernel/power/process.c | 114 ++---
4 files changed, 72 insertions(+), 58 deletions(-)
diff -ruNp 992-suspend_fix.patch-old/Documentation/power/kernel_threads.txt
992-suspend_fix.patch-new/Documentation/power/kernel_threads.txt
--- 992-suspend_fix.patch-old/Documentation/power/kernel_threads.txt
2005-08-08 17:23:31.0 +1000
+++ 992-suspend_fix.patch-new/Documentation/power/kernel_threads.txt
2005-08-09 08:11:41.0 +1000
@@ -4,15 +4,15 @@ KERNEL THREADS
Freezer
Upon entering a suspended state the system will freeze all
-tasks. This is done by delivering pseudosignals. This affects
-kernel threads, too. To successfully freeze a kernel thread
-the thread has to check for the pseudosignal and enter the
-refrigerator. Code to do this looks like this:
+tasks. This is done by making all processes execute a notifier.
+This affects kernel threads, too. To successfully freeze a kernel thread
+the thread has to check for the notifications and call the notifier
+chain for the process. Code to do this looks like this:
do {
hub_events();
wait_event_interruptible(khubd_wait,
!list_empty(hub_event_list));
- try_to_freeze();
+ try_todo_list();
} while (!signal_pending(current));
from drivers/usb/core/hub.c::hub_thread()
diff -ruNp 992-suspend_fix.patch-old/Documentation/power/swsusp.txt
992-suspend_fix.patch-new/Documentation/power/swsusp.txt
--- 992-suspend_fix.patch-old/Documentation/power/swsusp.txt2005-08-08
17:23:31.0 +1000
+++ 992-suspend_fix.patch-new/Documentation/power/swsusp.txt2005-08-09
08:11:41.0 +1000
@@ -155,7 +155,8 @@ should be sent to the mailing list avail
website, and not to the Linux Kernel Mailing List. We are working
toward merging suspend2 into the mainline kernel.
-Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
+Q: A kernel thread must work on the todo list (call 'run_todo_list')
+to enter the refrigerator.
I found some kernel threads that don't do it, and they don't freeze
so the system can't sleep. Is this a known behavior?
@@ -164,7 +165,7 @@ place where the thread is safe to be fro
should be held at that point and it must be safe to sleep there), and
add:
- try_to_freeze();
+ try_todo_list();
If the thread is needed for writing the image to storage, you should
instead set the PF_NOFREEZE process flag when creating the thread (and
diff -ruNp 992-suspend_fix.patch-old/include/linux/sched.h
992-suspend_fix.patch-new/include/linux/sched.h
--- 992-suspend_fix.patch-old/include/linux/sched.h 2005-08-09
11:17:49.0 +1000
+++ 992-suspend_fix.patch-new/include/linux/sched.h 2005-08-09
08:11:41.0 +1000
@@ -835,7 +835,6 @@ do { if (atomic_dec_and_test((tsk)-usa
#define PF_MEMALLOC0x0800 /* Allocating memory */
#define PF_FLUSHER 0x1000 /* responsible for disk writeback */
#define PF_USED_MATH 0x2000 /* if unset the fpu must be initialized
before use */
-#define PF_FREEZE 0x4000 /* this task is being frozen for
suspend now */
#define PF_NOFREEZE0x8000 /* this thread should not be frozen */
#define PF_FROZEN 0x0001 /* frozen for system suspend */
#define PF_FSTRANS 0x0002 /* inside a filesystem transaction */
diff -ruNp 992-suspend_fix.patch-old/kernel/power/process.c
992-suspend_fix.patch-new/kernel/power/process.c
--- 992-suspend_fix.patch-old/kernel/power/process.c2005-08-09
11:17:48.0 +1000
+++ 992-suspend_fix.patch-new/kernel/power/process.c2005-08-09
11:10:59.0 +1000
@@ -61,6 +61,11 @@ extern void suspend_relinquish_console(v
static void freeze_lru(void);
extern void thaw_lru(void);
+DECLARE_COMPLETION(kernelspace_thaw);
+DECLARE_COMPLETION(userspace_thaw);
+static atomic_t nr_userspace_frozen;
+static atomic_t nr_kernelspace_frozen;
+
/*
* to_be_frozen
*
@@ -72,7 +77,7 @@ extern void thaw_lru(void);
static int to_be_frozen(struct task_struct * p,
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Thu, 28 Jul 2005, Andrew Morton wrote: > Well if you want to go this way I can just drop the TIF_FREEZE stuff and > use the patches-relative-to-mainline. I would appreciate that.\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Fri, 29 Jul 2005, Pavel Machek wrote: > > > > Dont fix it up. Remove the ealier patch. > > > > Oops. Do you happen to have patch relative to -mm or something? I'd > > prefer not to mess it up second time... > > Ok. I will make a patch against mm tomorrow. Well if you want to go this way I can just drop the TIF_FREEZE stuff and use the patches-relative-to-mainline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Fri, 29 Jul 2005, Pavel Machek wrote: > > Dont fix it up. Remove the ealier patch. > > Oops. Do you happen to have patch relative to -mm or something? I'd > prefer not to mess it up second time... Ok. I will make a patch against mm tomorrow. Patches are typically against Linus latest and if you test against mm then you may see breakage from other patches. Plus there will be dependencies with other patches in mm. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! > > > > Introduce a todo notifier in the task_struct so that a task can be told > > > > to do > > > > certain things. Abuse the suspend hooks try_to_freeze, freezing and > > > > refrigerator > > > > to establish checkpoints where the todo list is processed. This will > > > > break software > > > > suspend (next patch fixes and cleans up software suspend). > > > > > > Ugh, this conflicts with stuff in -mm tree rather badly... In part > > > thanks to patch by you that was already applied. > > > > > > I fixed up rejects manually (but probably lost fix or two in > > > progress), and will test. > > Dont fix it up. Remove the ealier patch. Oops. Do you happen to have patch relative to -mm or something? I'd prefer not to mess it up second time... > > > You are doing rather intrusive changes. Is testing them too much to > > > ask? I'm pretty sure you can get i386 machine to test swsusp on... > > > > (And yes, I did apply the whole series. It would be nice if next > > series was relative to -mm, it already contains some of your changes). > > mm contains the TIF_FREEZE changes that need to be undone. And yes I > tested it on a i386 with suspend to disk and it worked fine. Sorry. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Thu, 28 Jul 2005, Pavel Machek wrote: > Hi! > > > > Introduce a todo notifier in the task_struct so that a task can be told > > > to do > > > certain things. Abuse the suspend hooks try_to_freeze, freezing and > > > refrigerator > > > to establish checkpoints where the todo list is processed. This will > > > break software > > > suspend (next patch fixes and cleans up software suspend). > > > > Ugh, this conflicts with stuff in -mm tree rather badly... In part > > thanks to patch by you that was already applied. > > > > I fixed up rejects manually (but probably lost fix or two in > > progress), and will test. Dont fix it up. Remove the ealier patch. > > > > You are doing rather intrusive changes. Is testing them too much to > > ask? I'm pretty sure you can get i386 machine to test swsusp on... > > (And yes, I did apply the whole series. It would be nice if next > series was relative to -mm, it already contains some of your changes). mm contains the TIF_FREEZE changes that need to be undone. And yes I tested it on a i386 with suspend to disk and it worked fine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! > Introduce a todo notifier in the task_struct so that a task can be told to do > certain things. Abuse the suspend hooks try_to_freeze, freezing and > refrigerator > to establish checkpoints where the todo list is processed. This will break > software > suspend (next patch fixes and cleans up software suspend). Ugh, this conflicts with stuff in -mm tree rather badly... In part thanks to patch by you that was already applied. I fixed up rejects manually (but probably lost fix or two in progress), and will test. Uff, and then it breaks suspend completely: Jul 28 23:21:12 amd kernel: Stopping tasks: =Restarting tasks...khpsbpkt: received unexpected signal?! Jul 28 23:21:12 amd kernel: NodeMgr: received unexpected signal?! Jul 28 23:21:22 amd kernel: done Jul 28 23:21:32 amd pam_limits[1547]: wrong limit value 'unlimited' (Left me with basically all kernel threads going crazy:) top - 23:22:34 up 3 min, 4 users, load average: 5.10, 1.90, 0.69 Tasks: 48 total, 2 running, 46 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0% us, 100.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2064480k total, 155664k used, 1908816k free,10280k buffers Swap: 2136448k total,0k used, 2136448k free, 114624k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 273 root 25 0 000 S 21.1 0.0 0:11.24 kswapd0 938 root 25 0 000 S 21.1 0.0 0:11.24 pccardd 940 root 25 0 000 S 21.1 0.0 0:11.30 pccardd 1060 root 25 0 000 R 21.1 0.0 0:21.34 kjournald 1409 root 25 0 000 S 17.3 0.0 0:19.71 kjournald You are doing rather intrusive changes. Is testing them too much to ask? I'm pretty sure you can get i386 machine to test swsusp on... Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! > > Introduce a todo notifier in the task_struct so that a task can be told to > > do > > certain things. Abuse the suspend hooks try_to_freeze, freezing and > > refrigerator > > to establish checkpoints where the todo list is processed. This will break > > software > > suspend (next patch fixes and cleans up software suspend). > > Ugh, this conflicts with stuff in -mm tree rather badly... In part > thanks to patch by you that was already applied. > > I fixed up rejects manually (but probably lost fix or two in > progress), and will test. > > Uff, and then it breaks suspend completely: > > Jul 28 23:21:12 amd kernel: Stopping tasks: > =Restarting tasks...khpsbpkt: > received unexpected signal?! > Jul 28 23:21:12 amd kernel: NodeMgr: received unexpected signal?! > Jul 28 23:21:22 amd kernel: done > Jul 28 23:21:32 amd pam_limits[1547]: wrong limit value 'unlimited' > > (Left me with basically all kernel threads going crazy:) > > top - 23:22:34 up 3 min, 4 users, load average: 5.10, 1.90, 0.69 > Tasks: 48 total, 2 running, 46 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.0% us, 100.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, > 0.0% si > Mem: 2064480k total, 155664k used, 1908816k free,10280k > buffers > Swap: 2136448k total,0k used, 2136448k free, 114624k > cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 273 root 25 0 000 S 21.1 0.0 0:11.24 kswapd0 > 938 root 25 0 000 S 21.1 0.0 0:11.24 pccardd > 940 root 25 0 000 S 21.1 0.0 0:11.30 pccardd > 1060 root 25 0 000 R 21.1 0.0 0:21.34 kjournald > 1409 root 25 0 000 S 17.3 0.0 0:19.71 kjournald > > You are doing rather intrusive changes. Is testing them too much to > ask? I'm pretty sure you can get i386 machine to test swsusp on... (And yes, I did apply the whole series. It would be nice if next series was relative to -mm, it already contains some of your changes). Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] Task notifier: Implement todo list in task_struct
Introduce a todo notifier in the task_struct so that a task can be told to do
certain things. Abuse the suspend hooks try_to_freeze, freezing and refrigerator
to establish checkpoints where the todo list is processed. This will break
software
suspend (next patch fixes and cleans up software suspend).
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3/include/linux/sched.h
===
--- linux-2.6.13-rc3.orig/include/linux/sched.h 2005-07-12 21:46:46.0
-0700
+++ linux-2.6.13-rc3/include/linux/sched.h 2005-07-28 11:54:40.0
-0700
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
struct exec_domain;
@@ -720,7 +721,10 @@
int (*notifier)(void *priv);
void *notifier_data;
sigset_t *notifier_mask;
-
+
+ /* todo list to be executed in the context of this thread */
+ struct notifier_block *todo;
+
void *security;
struct audit_context *audit_context;
seccomp_t seccomp;
@@ -1273,79 +1275,37 @@
#endif
-#ifdef CONFIG_PM
/*
- * Check if a process has been frozen
+ * Check if there is a todo list request
*/
-static inline int frozen(struct task_struct *p)
+static inline int todo_list_active(void)
{
- return p->flags & PF_FROZEN;
+ return current->todo != NULL;
}
-/*
- * Check if there is a request to freeze a process
- */
-static inline int freezing(struct task_struct *p)
+static inline void run_todo_list(void)
{
- return p->flags & PF_FREEZE;
+ notifier_call_chain(>todo, 0, current);
}
-/*
- * Request that a process be frozen
- * FIXME: SMP problem. We may not modify other process' flags!
- */
-static inline void freeze(struct task_struct *p)
+static inline int try_todo_list(void)
{
- p->flags |= PF_FREEZE;
-}
-
-/*
- * Wake up a frozen process
- */
-static inline int thaw_process(struct task_struct *p)
-{
- if (frozen(p)) {
- p->flags &= ~PF_FROZEN;
- wake_up_process(p);
- return 1;
- }
- return 0;
-}
-
-/*
- * freezing is complete, mark process as frozen
- */
-static inline void frozen_process(struct task_struct *p)
-{
- p->flags = (p->flags & ~PF_FREEZE) | PF_FROZEN;
-}
-
-extern void refrigerator(void);
-extern int freeze_processes(void);
-extern void thaw_processes(void);
-
-static inline int try_to_freeze(void)
-{
- if (freezing(current)) {
- refrigerator();
+ if (todo_list_active()) {
+ run_todo_list();
return 1;
} else
return 0;
}
-#else
-static inline int frozen(struct task_struct *p) { return 0; }
-static inline int freezing(struct task_struct *p) { return 0; }
-static inline void freeze(struct task_struct *p) { BUG(); }
-static inline int thaw_process(struct task_struct *p) { return 1; }
-static inline void frozen_process(struct task_struct *p) { BUG(); }
-
-static inline void refrigerator(void) {}
-static inline int freeze_processes(void) { BUG(); return 0; }
-static inline void thaw_processes(void) {}
-static inline int try_to_freeze(void) { return 0; }
+/*
+ * Compatibility definitions to use the suspend checkpoints for the task todo
list.
+ * These may be removed once all uses of try_to_free, refrigerator and
freezing
+ * have been removed.
+ */
+#define try_to_freeze try_todo_list
+#define refrigerator run_todo_list
+#define freezing(p) todo_list_active()
-#endif /* CONFIG_PM */
#endif /* __KERNEL__ */
#endif
Index: linux-2.6.13-rc3/kernel/signal.c
===
--- linux-2.6.13-rc3.orig/kernel/signal.c 2005-07-12 21:46:46.0
-0700
+++ linux-2.6.13-rc3/kernel/signal.c2005-07-28 10:46:49.0 -0700
@@ -213,7 +213,7 @@
fastcall void recalc_sigpending_tsk(struct task_struct *t)
{
if (t->signal->group_stop_count > 0 ||
- (freezing(t)) ||
+ (t->todo) ||
PENDING(>pending, >blocked) ||
PENDING(>signal->shared_pending, >blocked))
set_tsk_thread_flag(t, TIF_SIGPENDING);
@@ -2231,7 +2231,7 @@
current->state = TASK_INTERRUPTIBLE;
timeout = schedule_timeout(timeout);
- try_to_freeze();
+ try_todo_list();
spin_lock_irq(>sighand->siglock);
sig = dequeue_signal(current, , );
current->blocked = current->real_blocked;
Index: linux-2.6.13-rc3/arch/frv/kernel/signal.c
===
--- linux-2.6.13-rc3.orig/arch/frv/kernel/signal.c 2005-07-12
21:46:46.0 -0700
+++ linux-2.6.13-rc3/arch/frv/kernel/signal.c 2005-07-28 10:46:49.0
-0700
@@ -536,7 +536,7 @@
if (!user_mode(regs))
return 1;
- if (try_to_freeze())
+ if
[PATCH 2/4] Task notifier: Implement todo list in task_struct
Introduce a todo notifier in the task_struct so that a task can be told to do
certain things. Abuse the suspend hooks try_to_freeze, freezing and refrigerator
to establish checkpoints where the todo list is processed. This will break
software
suspend (next patch fixes and cleans up software suspend).
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Index: linux-2.6.13-rc3/include/linux/sched.h
===
--- linux-2.6.13-rc3.orig/include/linux/sched.h 2005-07-12 21:46:46.0
-0700
+++ linux-2.6.13-rc3/include/linux/sched.h 2005-07-28 11:54:40.0
-0700
@@ -34,6 +34,7 @@
#include linux/percpu.h
#include linux/topology.h
#include linux/seccomp.h
+#include linux/notifier.h
struct exec_domain;
@@ -720,7 +721,10 @@
int (*notifier)(void *priv);
void *notifier_data;
sigset_t *notifier_mask;
-
+
+ /* todo list to be executed in the context of this thread */
+ struct notifier_block *todo;
+
void *security;
struct audit_context *audit_context;
seccomp_t seccomp;
@@ -1273,79 +1275,37 @@
#endif
-#ifdef CONFIG_PM
/*
- * Check if a process has been frozen
+ * Check if there is a todo list request
*/
-static inline int frozen(struct task_struct *p)
+static inline int todo_list_active(void)
{
- return p-flags PF_FROZEN;
+ return current-todo != NULL;
}
-/*
- * Check if there is a request to freeze a process
- */
-static inline int freezing(struct task_struct *p)
+static inline void run_todo_list(void)
{
- return p-flags PF_FREEZE;
+ notifier_call_chain(current-todo, 0, current);
}
-/*
- * Request that a process be frozen
- * FIXME: SMP problem. We may not modify other process' flags!
- */
-static inline void freeze(struct task_struct *p)
+static inline int try_todo_list(void)
{
- p-flags |= PF_FREEZE;
-}
-
-/*
- * Wake up a frozen process
- */
-static inline int thaw_process(struct task_struct *p)
-{
- if (frozen(p)) {
- p-flags = ~PF_FROZEN;
- wake_up_process(p);
- return 1;
- }
- return 0;
-}
-
-/*
- * freezing is complete, mark process as frozen
- */
-static inline void frozen_process(struct task_struct *p)
-{
- p-flags = (p-flags ~PF_FREEZE) | PF_FROZEN;
-}
-
-extern void refrigerator(void);
-extern int freeze_processes(void);
-extern void thaw_processes(void);
-
-static inline int try_to_freeze(void)
-{
- if (freezing(current)) {
- refrigerator();
+ if (todo_list_active()) {
+ run_todo_list();
return 1;
} else
return 0;
}
-#else
-static inline int frozen(struct task_struct *p) { return 0; }
-static inline int freezing(struct task_struct *p) { return 0; }
-static inline void freeze(struct task_struct *p) { BUG(); }
-static inline int thaw_process(struct task_struct *p) { return 1; }
-static inline void frozen_process(struct task_struct *p) { BUG(); }
-
-static inline void refrigerator(void) {}
-static inline int freeze_processes(void) { BUG(); return 0; }
-static inline void thaw_processes(void) {}
-static inline int try_to_freeze(void) { return 0; }
+/*
+ * Compatibility definitions to use the suspend checkpoints for the task todo
list.
+ * These may be removed once all uses of try_to_free, refrigerator and
freezing
+ * have been removed.
+ */
+#define try_to_freeze try_todo_list
+#define refrigerator run_todo_list
+#define freezing(p) todo_list_active()
-#endif /* CONFIG_PM */
#endif /* __KERNEL__ */
#endif
Index: linux-2.6.13-rc3/kernel/signal.c
===
--- linux-2.6.13-rc3.orig/kernel/signal.c 2005-07-12 21:46:46.0
-0700
+++ linux-2.6.13-rc3/kernel/signal.c2005-07-28 10:46:49.0 -0700
@@ -213,7 +213,7 @@
fastcall void recalc_sigpending_tsk(struct task_struct *t)
{
if (t-signal-group_stop_count 0 ||
- (freezing(t)) ||
+ (t-todo) ||
PENDING(t-pending, t-blocked) ||
PENDING(t-signal-shared_pending, t-blocked))
set_tsk_thread_flag(t, TIF_SIGPENDING);
@@ -2231,7 +2231,7 @@
current-state = TASK_INTERRUPTIBLE;
timeout = schedule_timeout(timeout);
- try_to_freeze();
+ try_todo_list();
spin_lock_irq(current-sighand-siglock);
sig = dequeue_signal(current, these, info);
current-blocked = current-real_blocked;
Index: linux-2.6.13-rc3/arch/frv/kernel/signal.c
===
--- linux-2.6.13-rc3.orig/arch/frv/kernel/signal.c 2005-07-12
21:46:46.0 -0700
+++ linux-2.6.13-rc3/arch/frv/kernel/signal.c 2005-07-28 10:46:49.0
-0700
@@ -536,7 +536,7 @@
if (!user_mode(regs))
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! Introduce a todo notifier in the task_struct so that a task can be told to do certain things. Abuse the suspend hooks try_to_freeze, freezing and refrigerator to establish checkpoints where the todo list is processed. This will break software suspend (next patch fixes and cleans up software suspend). Ugh, this conflicts with stuff in -mm tree rather badly... In part thanks to patch by you that was already applied. I fixed up rejects manually (but probably lost fix or two in progress), and will test. Uff, and then it breaks suspend completely: Jul 28 23:21:12 amd kernel: Stopping tasks: =Restarting tasks...khpsbpkt: received unexpected signal?! Jul 28 23:21:12 amd kernel: NodeMgr: received unexpected signal?! Jul 28 23:21:22 amd kernel: done Jul 28 23:21:32 amd pam_limits[1547]: wrong limit value 'unlimited' (Left me with basically all kernel threads going crazy:) top - 23:22:34 up 3 min, 4 users, load average: 5.10, 1.90, 0.69 Tasks: 48 total, 2 running, 46 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0% us, 100.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2064480k total, 155664k used, 1908816k free,10280k buffers Swap: 2136448k total,0k used, 2136448k free, 114624k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 273 root 25 0 000 S 21.1 0.0 0:11.24 kswapd0 938 root 25 0 000 S 21.1 0.0 0:11.24 pccardd 940 root 25 0 000 S 21.1 0.0 0:11.30 pccardd 1060 root 25 0 000 R 21.1 0.0 0:21.34 kjournald 1409 root 25 0 000 S 17.3 0.0 0:19.71 kjournald You are doing rather intrusive changes. Is testing them too much to ask? I'm pretty sure you can get i386 machine to test swsusp on... (And yes, I did apply the whole series. It would be nice if next series was relative to -mm, it already contains some of your changes). Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! Introduce a todo notifier in the task_struct so that a task can be told to do certain things. Abuse the suspend hooks try_to_freeze, freezing and refrigerator to establish checkpoints where the todo list is processed. This will break software suspend (next patch fixes and cleans up software suspend). Ugh, this conflicts with stuff in -mm tree rather badly... In part thanks to patch by you that was already applied. I fixed up rejects manually (but probably lost fix or two in progress), and will test. Uff, and then it breaks suspend completely: Jul 28 23:21:12 amd kernel: Stopping tasks: =Restarting tasks...khpsbpkt: received unexpected signal?! Jul 28 23:21:12 amd kernel: NodeMgr: received unexpected signal?! Jul 28 23:21:22 amd kernel: done Jul 28 23:21:32 amd pam_limits[1547]: wrong limit value 'unlimited' (Left me with basically all kernel threads going crazy:) top - 23:22:34 up 3 min, 4 users, load average: 5.10, 1.90, 0.69 Tasks: 48 total, 2 running, 46 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0% us, 100.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2064480k total, 155664k used, 1908816k free,10280k buffers Swap: 2136448k total,0k used, 2136448k free, 114624k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 273 root 25 0 000 S 21.1 0.0 0:11.24 kswapd0 938 root 25 0 000 S 21.1 0.0 0:11.24 pccardd 940 root 25 0 000 S 21.1 0.0 0:11.30 pccardd 1060 root 25 0 000 R 21.1 0.0 0:21.34 kjournald 1409 root 25 0 000 S 17.3 0.0 0:19.71 kjournald You are doing rather intrusive changes. Is testing them too much to ask? I'm pretty sure you can get i386 machine to test swsusp on... Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Thu, 28 Jul 2005, Pavel Machek wrote: Hi! Introduce a todo notifier in the task_struct so that a task can be told to do certain things. Abuse the suspend hooks try_to_freeze, freezing and refrigerator to establish checkpoints where the todo list is processed. This will break software suspend (next patch fixes and cleans up software suspend). Ugh, this conflicts with stuff in -mm tree rather badly... In part thanks to patch by you that was already applied. I fixed up rejects manually (but probably lost fix or two in progress), and will test. Dont fix it up. Remove the ealier patch. You are doing rather intrusive changes. Is testing them too much to ask? I'm pretty sure you can get i386 machine to test swsusp on... (And yes, I did apply the whole series. It would be nice if next series was relative to -mm, it already contains some of your changes). mm contains the TIF_FREEZE changes that need to be undone. And yes I tested it on a i386 with suspend to disk and it worked fine. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! Introduce a todo notifier in the task_struct so that a task can be told to do certain things. Abuse the suspend hooks try_to_freeze, freezing and refrigerator to establish checkpoints where the todo list is processed. This will break software suspend (next patch fixes and cleans up software suspend). Ugh, this conflicts with stuff in -mm tree rather badly... In part thanks to patch by you that was already applied. I fixed up rejects manually (but probably lost fix or two in progress), and will test. Dont fix it up. Remove the ealier patch. Oops. Do you happen to have patch relative to -mm or something? I'd prefer not to mess it up second time... You are doing rather intrusive changes. Is testing them too much to ask? I'm pretty sure you can get i386 machine to test swsusp on... (And yes, I did apply the whole series. It would be nice if next series was relative to -mm, it already contains some of your changes). mm contains the TIF_FREEZE changes that need to be undone. And yes I tested it on a i386 with suspend to disk and it worked fine. Sorry. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Fri, 29 Jul 2005, Pavel Machek wrote: Dont fix it up. Remove the ealier patch. Oops. Do you happen to have patch relative to -mm or something? I'd prefer not to mess it up second time... Ok. I will make a patch against mm tomorrow. Patches are typically against Linus latest and if you test against mm then you may see breakage from other patches. Plus there will be dependencies with other patches in mm. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Christoph Lameter [EMAIL PROTECTED] wrote: On Fri, 29 Jul 2005, Pavel Machek wrote: Dont fix it up. Remove the ealier patch. Oops. Do you happen to have patch relative to -mm or something? I'd prefer not to mess it up second time... Ok. I will make a patch against mm tomorrow. Well if you want to go this way I can just drop the TIF_FREEZE stuff and use the patches-relative-to-mainline. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Thu, 28 Jul 2005, Andrew Morton wrote: Well if you want to go this way I can just drop the TIF_FREEZE stuff and use the patches-relative-to-mainline. I would appreciate that.\ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
