linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* SCHED_BATCH not stopped (swsusp fails)
@ 2005-01-07 19:16 Rajsekar
  2005-01-10 22:32 ` Pavel Machek
  0 siblings, 1 reply; 5+ messages in thread
From: Rajsekar @ 2005-01-07 19:16 UTC (permalink / raw)
  To: linux-kernel


SCHED_BATCH processes dont seem to heed the `stop' request (order?) by
swsusp.  I run httpd and mysqld (for my wiki page) with SCHED_BATCH (so
that I can work on my computer even if the load is very high) but when I
try to suspend the system, it tries to stop the tasks and simply returns.
Here is the dmesg output (paritial)

#dmesg
....
....
Stopping tasks: =======================================
 stopping tasks failed (20 tasks remaining)
Restarting tasks...<6> Strange, mysqld not stopped
 Strange, mysqld not stopped
 Strange, mysqld not stopped
 Strange, mysqld not stopped
 Strange, mysqld not stopped
 Strange, mysqld not stopped
 Strange, mysqld not stopped
 Strange, mysqld not stopped
 Strange, mysqld not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 Strange, httpd not stopped
 done
===================


-- 
    Rajsekar


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SCHED_BATCH not stopped (swsusp fails)
  2005-01-07 19:16 SCHED_BATCH not stopped (swsusp fails) Rajsekar
@ 2005-01-10 22:32 ` Pavel Machek
  2005-01-10 23:18   ` Con Kolivas
  0 siblings, 1 reply; 5+ messages in thread
From: Pavel Machek @ 2005-01-10 22:32 UTC (permalink / raw)
  To: Rajsekar; +Cc: linux-kernel

Hi!

> SCHED_BATCH processes dont seem to heed the `stop' request (order?) by
> swsusp.  I run httpd and mysqld (for my wiki page) with SCHED_BATCH (so
> that I can work on my computer even if the load is very high) but when I
> try to suspend the system, it tries to stop the tasks and simply returns.
> Here is the dmesg output (paritial)

Aha, so if it mysqld is not running SCHED_BATCH priority, stopping
mysqld will work ok?
								Pavel

> #dmesg
> ....
> ....
> Stopping tasks: =======================================
>  stopping tasks failed (20 tasks remaining)
> Restarting tasks...<6> Strange, mysqld not stopped
>  Strange, mysqld not stopped
>  Strange, mysqld not stopped
>  Strange, mysqld not stopped


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SCHED_BATCH not stopped (swsusp fails)
  2005-01-10 22:32 ` Pavel Machek
@ 2005-01-10 23:18   ` Con Kolivas
       [not found]     ` <20050110234456.GC1444@elf.ucw.cz>
  0 siblings, 1 reply; 5+ messages in thread
From: Con Kolivas @ 2005-01-10 23:18 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Rajsekar, linux-kernel

Pavel Machek wrote:
> Hi!
> 
> 
>>SCHED_BATCH processes dont seem to heed the `stop' request (order?) by
>>swsusp.  I run httpd and mysqld (for my wiki page) with SCHED_BATCH (so
>>that I can work on my computer even if the load is very high) but when I
>>try to suspend the system, it tries to stop the tasks and simply returns.
>>Here is the dmesg output (paritial)
> 
> 
> Aha, so if it mysqld is not running SCHED_BATCH priority, stopping
> mysqld will work ok?

That makes sense.

Sorry, SCHED_BATCH is unique to my tree at the moment so this is my 
mistake for not considering it. I'll have to transiently schedule 
SCHED_BATCH tasks as SCHED_NORMAL if we are going into swsusp. It's 
something I'll have to work on. In the interim, a workaround would be to 
convert all httpd threads to SCHED_NORMAL before shutting down in your 
scripts somewhere and convert them back after resuming.

Cheers,
Con

P.S. Raj the --cutme-- thing in your email is very annoying for those of 
us who reply to up to 300 emails a day (and yes I do know why you do it, 
but if you keep doing it people will stop replying directly to you).

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SCHED_BATCH not stopped (swsusp fails)
       [not found]         ` <41E3D6B4.2080706@kolivas.org>
@ 2005-01-11 20:23           ` Rajsekar
  2005-01-11 22:23             ` Con Kolivas
  0 siblings, 1 reply; 5+ messages in thread
From: Rajsekar @ 2005-01-11 20:23 UTC (permalink / raw)
  To: Con Kolivas; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

Con Kolivas <kernel@kolivas.org> writes:

> Rajsekar wrote:
>> Pavel Machek <pavel@ucw.cz> writes:
>>
>>>Hi!
>>>
>>>
>>>>>>SCHED_BATCH processes dont seem to heed the `stop' request (order?) by
>>>>>>swsusp.  I run httpd and mysqld (for my wiki page) with SCHED_BATCH (so
>>>>>>that I can work on my computer even if the load is very high) but when I
>>>>>>try to suspend the system, it tries to stop the tasks and simply returns.
>>>>>>Here is the dmesg output (paritial)
>>>>>
>>>>>
>>>>>Aha, so if it mysqld is not running SCHED_BATCH priority, stopping
>>>>>mysqld will work ok?
>>>>
>>>>That makes sense.
>>>>
>>>> Sorry, SCHED_BATCH is unique to my tree at the moment so this is my mistake for not considering it. I'll have to
>>>> transiently schedule SCHED_BATCH tasks as SCHED_NORMAL if we are going into swsusp. It's something I'll have to work
>>>> on. In the interim, a workaround would be to convert all httpd threads to SCHED_NORMAL before shutting down in your
>>>> scripts somewhere and convert them back after resuming.
>>>>
>>>>Cheers,
>>>>Con
>>>>
>>>> P.S. Raj the --cutme-- thing in your email is very annoying for those of us who reply to up to 300 emails a day (and
>>>> yes I do know why you do it, but if you keep doing it people will stop replying directly to you).
>>>
>>>Seconded. And by now your email address is in l-k, so you might simply
>>>give it up :-).
>>>								Pavel
>>> -- 
>>>People were complaining that M$ turns users into beta-testers...
>>>...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
>> Can you give me some ideas on how to go about it? Or why exactly
>> SCHED_BATCH does not respond to SIGSTOP (is it because of UNINTERRUPTIBLE
>> sleep)?
>
> I'm trying a patch to help it work properly; I haven't been able to test it. It is going into ck3. If you want you can
> try just that patch on your current kernel or download ck3.
>
> The small patch is attached.
>
> Cheers,
> Con
>
> Index: linux-2.6.10-ck3/kernel/power/process.c
> ===================================================================
> --- linux-2.6.10-ck3.orig/kernel/power/process.c	2005-01-11 22:44:13.000000000 +1100
> +++ linux-2.6.10-ck3/kernel/power/process.c	2005-01-11 22:58:39.367058561 +1100
> @@ -68,6 +68,12 @@ int freeze_processes(void)
>  		read_lock(&tasklist_lock);
>  		do_each_thread(g, p) {
>  			unsigned long flags;
> +			if (batch_task(p))
> +				p->flags |= PF_UISLEEP;
> +				/*
> +				 * This will make batch tasks run SCHED_NORMAL
> +				 * too allow them to be frozen.
> +				 */
>  			if (!freezeable(p))
>  				continue;
>  			if ((p->flags & PF_FROZEN) ||
>
>

Your patch did not solve the problem.
The problem is that after you set the PF_UISLEEP flag, but no where else is it
checked.  My idea is to ignore freezing the PF_UISLEEP processes (hoping
they wont wake up in the mean time) and just adding another condition.  I
had add just one more line of code to make it work.  May be that it has
been added in swsusp and mine is out of date.

Could you tell me if what I have done is right?


[-- Attachment #2: Patch File --]
[-- Type: text/plain, Size: 767 bytes --]

diff -Naur orig/kernel/power/process.c changed/kernel/power/process.c
--- orig/kernel/power/process.c	2005-01-12 01:49:52.846791528 +0530
+++ changed/kernel/power/process.c	2005-01-12 01:50:02.800278368 +0530
@@ -23,6 +23,7 @@
 {
 	if ((p == current) || 
 	    (p->flags & PF_NOFREEZE) ||
+	    (p->flags & PF_UISLEEP) ||
 	    (p->exit_state == EXIT_ZOMBIE) ||
 	    (p->exit_state == EXIT_DEAD) ||
 	    (p->state == TASK_STOPPED) ||
@@ -68,6 +69,12 @@
 		read_lock(&tasklist_lock);
 		do_each_thread(g, p) {
 			unsigned long flags;
+			if (batch_task(p))
+				p->flags |= PF_UISLEEP;
+				/*
+				 * This will make batch tasks run SCHED_NORMAL
+				 * too allow them to be frozen.
+				 */
 			if (!freezeable(p))
 				continue;
 			if ((p->flags & PF_FROZEN) ||

[-- Attachment #3: Type: text/plain, Size: 44 bytes --]



-- 
    Rajsekar Manokaran
    IIT Madras

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SCHED_BATCH not stopped (swsusp fails)
  2005-01-11 20:23           ` Rajsekar
@ 2005-01-11 22:23             ` Con Kolivas
  0 siblings, 0 replies; 5+ messages in thread
From: Con Kolivas @ 2005-01-11 22:23 UTC (permalink / raw)
  To: Rajsekar; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 4129 bytes --]

Rajsekar wrote:
> Con Kolivas <kernel@kolivas.org> writes:
> 
> 
>>Rajsekar wrote:
>>
>>>Pavel Machek <pavel@ucw.cz> writes:
>>>
>>>
>>>>Hi!
>>>>
>>>>
>>>>
>>>>>>>SCHED_BATCH processes dont seem to heed the `stop' request (order?) by
>>>>>>>swsusp.  I run httpd and mysqld (for my wiki page) with SCHED_BATCH (so
>>>>>>>that I can work on my computer even if the load is very high) but when I
>>>>>>>try to suspend the system, it tries to stop the tasks and simply returns.
>>>>>>>Here is the dmesg output (paritial)
>>>>>>
>>>>>>
>>>>>>Aha, so if it mysqld is not running SCHED_BATCH priority, stopping
>>>>>>mysqld will work ok?
>>>>>
>>>>>That makes sense.
>>>>>
>>>>>Sorry, SCHED_BATCH is unique to my tree at the moment so this is my mistake for not considering it. I'll have to
>>>>>transiently schedule SCHED_BATCH tasks as SCHED_NORMAL if we are going into swsusp. It's something I'll have to work
>>>>>on. In the interim, a workaround would be to convert all httpd threads to SCHED_NORMAL before shutting down in your
>>>>>scripts somewhere and convert them back after resuming.
>>>>>
>>>>>Cheers,
>>>>>Con
>>>>>
>>>>>P.S. Raj the --cutme-- thing in your email is very annoying for those of us who reply to up to 300 emails a day (and
>>>>>yes I do know why you do it, but if you keep doing it people will stop replying directly to you).
>>>>
>>>>Seconded. And by now your email address is in l-k, so you might simply
>>>>give it up :-).
>>>>								Pavel
>>>>-- 
>>>>People were complaining that M$ turns users into beta-testers...
>>>>...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
>>>
>>>Can you give me some ideas on how to go about it? Or why exactly
>>>SCHED_BATCH does not respond to SIGSTOP (is it because of UNINTERRUPTIBLE
>>>sleep)?
>>
>>I'm trying a patch to help it work properly; I haven't been able to test it. It is going into ck3. If you want you can
>>try just that patch on your current kernel or download ck3.
>>
>>The small patch is attached.
>>
>>Cheers,
>>Con
>>
>>Index: linux-2.6.10-ck3/kernel/power/process.c
>>===================================================================
>>--- linux-2.6.10-ck3.orig/kernel/power/process.c	2005-01-11 22:44:13.000000000 +1100
>>+++ linux-2.6.10-ck3/kernel/power/process.c	2005-01-11 22:58:39.367058561 +1100
>>@@ -68,6 +68,12 @@ int freeze_processes(void)
>> 		read_lock(&tasklist_lock);
>> 		do_each_thread(g, p) {
>> 			unsigned long flags;
>>+			if (batch_task(p))
>>+				p->flags |= PF_UISLEEP;
>>+				/*
>>+				 * This will make batch tasks run SCHED_NORMAL
>>+				 * too allow them to be frozen.
>>+				 */
>> 			if (!freezeable(p))
>> 				continue;
>> 			if ((p->flags & PF_FROZEN) ||
>>
>>
> 
> 
> Your patch did not solve the problem.
> The problem is that after you set the PF_UISLEEP flag, but no where else is it
> checked.  My idea is to ignore freezing the PF_UISLEEP processes (hoping
> they wont wake up in the mean time) and just adding another condition.  I
> had add just one more line of code to make it work.  May be that it has
> been added in swsusp and mine is out of date.
> 
> Could you tell me if what I have done is right?

Adding the UISLEEP flag was just reusing a flag that is unique in the 
staircase cpu scheduler and makes SCHED_BATCH run as SCHED_NORMAL next 
timeslice (it is used to prevent DoSing with held semaphores from 
SCHED_BATCH). Unfortunately it doesn't seem to make them SCHED_NORMAL 
long enough to run for a bit and then be frozen by swsusp. The batch 
tasks do need to be frozen like the rest. What you are doing is making 
swsusp not even try to freeze SCHED_BATCH processes. I suspect this is 
dangerous as you'll lose data to a suspend by ignoring processes that 
are actually running.

I still don't have time to study the swsusp code much more to figure out 
how to do this properly.

You can still do it in userspace for httpd2 for example with
for i in `/sbin/pidof httpd2`
do
	schedtool -N $i
done

to convert them to SCHED_NORMAL in your swsusp scripts before it tries 
to suspend, and then on wakeup do:
for i in `/sbin/pidof httpd2`
do
	schedtool -B $i
done

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-01-11 22:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-07 19:16 SCHED_BATCH not stopped (swsusp fails) Rajsekar
2005-01-10 22:32 ` Pavel Machek
2005-01-10 23:18   ` Con Kolivas
     [not found]     ` <20050110234456.GC1444@elf.ucw.cz>
     [not found]       ` <m38y70t7lo.fsf@rajsekar.pc>
     [not found]         ` <41E3D6B4.2080706@kolivas.org>
2005-01-11 20:23           ` Rajsekar
2005-01-11 22:23             ` Con Kolivas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).