Re: [Patch] Per kthread freezer flags

[Andrew Morton <akpm@osdl.org>]

Nigel Cunningham <ncunningham@linuxmail.org> wrote:
>
> At the moment, all kthreads have PF_NOFREEZE set, meaning that they're
> not refrigerated during a suspend. This isn't right for some threads.
> They should be frozen while suspending. The attached patch implements
> per-kthread freezer flags. It does this by adding a new parameter to the
> create_workqueue call and its siblings. The new parameter contains the
> process flags relevant to suspending to be set. At the moment, this only
> means PF_FREEZE, but when I send the freezer improvements, a
> PF_SYNCTHREAD flag will also be valid here. The new parameter is passed
> down through the calls and applied (after masking invalid bits) once the
> thread is created.
> 
> Pavel has seen the code and requested that I send it.
> 
> Regards,
> 
> Nigel
> 
> diff -ruN linux-2.6.8-rc1-mm1/drivers/acpi/osl.c linux-2.6.8-rc1-mm1-kthread_refrigerator/drivers/acpi/osl.c
> --- linux-2.6.8-rc1-mm1/drivers/acpi/osl.c	2004-07-28 16:37:46.000000000 +1000
> +++ linux-2.6.8-rc1-mm1-kthread_refrigerator/drivers/acpi/osl.c	2004-07-28 16:43:48.000000000 +1000
> @@ -81,7 +81,7 @@
>  		return AE_NULL_ENTRY;
>  	}
>  #endif
> -	kacpid_wq = create_singlethread_workqueue("kacpid");
> +	kacpid_wq = create_singlethread_workqueue("kacpid", 0);

hm.  In some ways I'd prefer to see new
create_singlethread_workqueue_freezer(char *) or whatever, rather than
adding an extra argument.  That's neater, smaller code and
forward-compatible.

But then again, the advantage of breaking the build for unconverted code is
that it makes people think about what their threads should be doing, so
let's go your way.

The one concern I'd have is that $RANDOM_KERNEL_DEVELOPER probably doesn't
have a clue whether or not his kernel thread should be setting PF_NOFREEZE.
What are the guidelines here?

wrt your "Add missing refrigerator support" patch: I'll suck that up, but
be aware that there's a big i2o patch in -mm which basically rips out the
driver which you just fixed up.  Perhaps you can send Markus Lidel
<Markus.Lidel@shadowconnect.com> and I a fix for that version of the driver
sometime?