On Tue, Feb 03, 2009 at 12:48:34PM +0000, Catalin Marinas wrote:
> On Tue, 2009-02-03 at 01:41 +0100, Frederic Weisbecker wrote:
> > Right. BTW, I wonder how it behaves in case of suspend to disk.
> > But changing the state to TASK_INTERRUPTIBLE wouldn't change it in this case since the
> > signals are only sent to userpace threads to freeze them.
I made a mistake here. Only kernel threads in TASK_INTERRUPTIBLE are woken up
while hibernation.
Yes, if you want kmemleak to be freezable, that's the right state.
> > Kernel threads try to freeze by themselves.
> >
> > But for such very long schedule_timeout, will the hibernation wait for kmemleak
> > to wake up and then try_to_freeze() before suspend to disk?
>
> I haven't added anything to kmemleak for this. Does something like below
> look feasible?
>
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -88,6 +88,7 @@
> #include <linux/errno.h>
> #include <linux/uaccess.h>
> #include <linux/string.h>
> +#include <linux/freezer.h>
>
> #include <asm/sections.h>
> #include <asm/processor.h>
> @@ -1070,8 +1071,11 @@ static int kmemleak_scan_thread(void *arg)
>
> mutex_unlock(&scan_mutex);
> /* wait before the next scan */
> - while (timeout && !kthread_should_stop())
> + while (timeout && !kthread_should_stop()) {
> + if (try_to_freeze())
> + break;
> timeout = schedule_timeout_interruptible(timeout);
> + }
> }
That looks good, but you have to set kmemleak thread as freezable before
by calling set_freezable() in the beggining of your thread.
Note that requiring kmemleak to be freezable looks only relevant if it does
some memory allocations (hibernation needs some memory and prefer that there
are not too much parallel memory allocations.)
>
> pr_info("kmemleak: Automatic memory scanning thread ended\n");
>
> Thanks.
>
> --
> Catalin
>
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
