On Thu, Feb 15, 2007 at 02:31:08PM +0100, Rafael J. Wysocki wrote: > > So I think tonight I'll start adding try_to_freeze() to the kernel threads > that > set PF_NOFREEZE.
cool! While you are at it, let me try to enhance the freezer api's to incorporate the PFE_* flags. > > > > That would still mean going over the task list twice. > > Yes, but I think this is inevitable anyway, because we have moved the > disabling of nonboot CPUs after the suspending of devices (for > ACPI-related reasons). > > Currently, we have, roughly: > > freeze_processes(); > shrink_memory(); (swsusp only) > suspend_devices(); > disable_nonboot_cpus(); > suspend > > and the reverse during the resume. > > Still, the second pass will be quick, since the majority of tasks are frozen > when disable_nonboot_cpus() is called. Ok. That's fine by me. Lets get it working first. We can always optimize it later :-) > > > > Cool! Lets get started then ;-) > > No problem with that. ;-) > > Speaking of the classification, do you think it would be practical to use > some kind of "freezing levels"? I mean, for each task we can define the > "freezing level" at which it should be frozen and each user of the freezer > can call it with a specific "freezing level" as a parameter. Of course for > this purpose the tasks frozen at level 1 have to be a subset of the tasks > frozen at level 2 etc. and I'm not sure if this requirement can be satisfied. A freeze hierarchy! I hope this freeze_level parameter ain't an alternative to the PFE_* flags because then a task would be in a dilemma as to what freezing level it should be at, if it wants to be frozen for lets say kprobes but not for cpu-hotplug. Cpu-hotplug and kprobes may not have a dependency like the one that exists between cpu-hotplug and suspend. So, at this moment, even I am not sure if there is a need for the hierarchy. > > Rafael Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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/
