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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Apr 2007 08:16:12 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Gautham R Shenoy <ego@...ibm.com>
Cc:	akpm@...ux-foundation.org, paulmck@...ibm.com,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	vatsa@...ibm.com, Oleg Nesterov <oleg@...sign.ru>,
	"Rafael J. Wysocki" <rjw@...k.pl>, dipankar@...ibm.com,
	dino@...ibm.com, masami.hiramatsu.pt@...achi.com
Subject: Re: [RFC] Cpu-hotplug: Using the Process Freezer (try2)

* Gautham R Shenoy <ego@...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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/