* Srivatsa Vaddagiri <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
