Messages in this thread | | | Date | Mon, 2 Apr 2007 13:18:28 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC] Cpu-hotplug: Using the Process Freezer (try2) |
| |
* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |