Re: [RFC] Cpu-hotplug: Using the Process Freezer (try2)

[Ingo Molnar <mingo@elte.hu>]

* Srivatsa Vaddagiri <vatsa@in.ibm.com> wrote:

> On Mon, Apr 02, 2007 at 08:16:12AM +0200, Ingo Molnar wrote:
> > hm, shouldnt the make be frozen immediately?
> > 
> > doesnt the 'please freeze ASAP' flag get propagated to all tasks, 
> > immediately? After that point any cloning activity should duplicate 
> > that flag too, resulting in any new child freezing immediately too.
> 
> afaics, setting the 'please freeze asap' flag is racy wrt 
> dup_task_struct (where the child's tsk->thread_info->flags are copied 
> from its parent?). Secondly, from what I understand, it takes a 'flag 
> to be set + signal marked pending' for the child task to be frozen. If 
> that is the case, then copy_process may not propogae the signal to the 
> child, which could mean mean that we can be in a catch-up game in 
> freeze_processes, trying to freeze processes we didnt see in earlier 
> passes.
> 
> I think copy_process() can check for something like this:
> 
> 	write_lock_irq(&tasklist_lock);
> 
> 	...
> 
> 	if (freezing(current))
> 		freeze_process(p);	/* function exported by freezer */

yeah. (is that safe with tasklist_lock held?)

i'm wondering whether we could do even better than the signal approach. 
I _think_ the best approach would be to only wait for tasks that are _on 
the runqueue_. I.e. any task that has scheduled away with 
TASK_UNINTERRUPTIBLE (and might not be able to process signal events for 
a long time) is still freezable because it scheduled away.

the only freeze-unsafe task is one that is on the runqueue, executing 
some unknown kernel code. But the number of those is typically pretty 
low, even with very large make -j task-counts.

now, the current approach approximates that set of tasks, but not 
completely: in particular TASK_UNINTERRUPTIBLE sleeping threads can 
introduce arbitrary long delays (and hence freezing failures). [in 
addition to any fork-related 'leaks' of freeze-notification]

	Ingo