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

[Ingo Molnar <mingo@elte.hu>]

* Gautham R Shenoy <ego@in.ibm.com> wrote:

> Hello Everybody,
> 
> This is another attempt towards process-freezer based cpu-hotplug. 
> This patchset covers just about everything that was discussed on the 
> LKML with respect to the freezer-based cpu-hotplug.

wow - you have made really nice progress!

> I believe that the reasons for freezer failing as N increases are :
> - 'make -jN' keeps forking new tasks every now and then, thereby resulting
>   in a never-ending catching up game in the do_while loop inside
>   try_to_freeze_tasks (kernel/power/process.c)

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.

> Instead of waiting for all the tasks to call try_to_freeze in the 
> above mentioned do_while loop, I wonder if we can put some hooks in 
> sched.c so asto not schedule the task marked PF_FREEZING/PF_FROZEN.

we could definitely do that - but i think it should be unnecessary: if 
we mark all tasks as PF_FREEZING atomically, that should result in 
_every_ task immediately dropping dead (once they get back from 
TASK_UNINTERRUPTIBLE). No excuses. If there's some longer delay then 
that can only be explained by some new cloned task/thread slipping 
through the net somehow. (i.e. the PF_FREEZING flag not being duplicated 
across fork?)

i'm wondering about how TASK_UNINTERRUPTIBLE tasks are handled by the 
freezer: are they assumed frozen immediately, or do we wait until they 
notice their PF_FREEZING and go into try_to_freeze()? I'd expect 
TASK_UNINTERRUPTIBLE to be the largest source of latency. (and hence be 
the primary source for freezing 'failures')

	Ingo